SDT - Security Roles / Tasks and Errors

(0) Share

Report

Posted on by Kevin Day

610

I am testing out the Script Debugger in my GP 10 Development Environment. Everything seems to be fine, but in my current setup, the GP security is tightly controlled and audited. Basically, it is a big company and all users generally have a defined Role. Some Key A/P Invoices, some only manage Vendor Records, some A/R Collections, some Finance Users, etc... So generally we assign one Role to a user in a company to make it easy to Audit. We have 200+ user accounts and 50 + company databases.

To the point or my post..... I can't have this tool assign the MBS_DEBUGGER_USER role to every user / company combination. I also don't want to assign the MBS Tasks to all the Roles. Here was my idea (that didn't work, sort of. In theory it should be fine)

Add the 7 Security Operation from the MBS_DEBUGGER_01 Task to the DEFAULTUSER task since everyone gets it. Add all 5 MBS_DEBUGGER tasks to the one ADMINISTRATOR role (which a couple of us are and we can do everything, similar to Power User)

They I want to Delete the 2 Roles that come with the Tool. Now everyone has appropriate access.

But I am getting a bunch of errors logging in now, script errors logging in. It also keeps asking me if I want to Assign the MBS Debugger User Role to all users. No I don't, and I've even deleted it.

Does anyone have any way around this message? I clicked 'Yes' once and it added 4000+ combinations to the User/Company/Role table which I don't want.

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (1)

L Vail 65,271 on at

Like (0)

Report

Hi

What happens if you leave the roles in place but just remove all of the tasks from the roles?

Kind regards,

Leslie

Was this reply helpful? Yes No
Kevin Day 610 on at

Like (0)

Report

Well, I already deleted the roles, but it seems next time I logged in, it re-created them. When I unchecked the tasks from the Roles, I got a few errors on next login

Unhandled script exception:

Illegal address for field 'Security Task Category' in script 'AddTaskToRole'. Script terminated.

then a message box with

"Could Not Run File Trigger Script"

This happened about 5 times, then I got the message again about "Do you want to add the role to all users"

I click no, but I think that it will continuously ask me ever time I log in.

Was this reply helpful? Yes No
L Vail 65,271 on at

Like (0)

Report

Hmm,

This is something David Musgrave will definitely want to know about. I'm surprised he hasn't already let us know what we're missing.

I'll slip him an e-mail and see if he can help.

Kind regards,

Leslie

Was this reply helpful? Yes No
Verified answer

David Musgrave MVP ... 14,093 Most Valuable Professional on at

Like (0)

Report

Hi Leslie

Thanks for the email.

Hi Kevin

Please don't delete or change the tasks and roles created by the Support Debugging Tool as they will be restored or updated on next login. You can just leave them if you really don't want to use them.

To stop the Support Debugging Tool running its installation questions, you need to have the MBS Debugger User Security Role assigned to at least one user. If the MBS Debugger User Security Role is not assigned to any users (and there are non POWERUSERS in the system), then the SDT decides this is a new install and starts the installation questions.

It would be best that you use the roles provided by the Support Debugging Tool, as they will be updated when new features are added to the tool which would then automatically work for your system.

David

Was this reply helpful? Yes No
Kevin Day 610 on at

Like (0)

Report

Thanks. As a workaround, it seems like if I add that Role to at least one user in one company, it doesn't prompt me to assign it to all users upon login. I can assign it to the sa user because that isn't a user that we look at to Audit Roles assigned because obviously it is the sa account and is just assumed to have everything.

Was this reply helpful? Yes No
David Musgrave MVP ... 14,093 Most Valuable Professional on at

Like (0)

Report

Hi Kevin

Glad I could help

David

Was this reply helpful? Yes No
Jerry Bierema 155 on at

Like (0)

Report

So, to follow, is Kevin's Unhandled Script Exception the result of manual manipulation of the MBS_DEBUGGER task or something else?

Thanks

Jerry

Was this reply helpful? Yes No
David Musgrave MVP ... 14,093 Most Valuable Professional on at

Like (0)

Report

Hi Jerry and Kevin

Based on the message, the exceptions are caused by a table trigger registered against the Security Task table from another 3rd party product. The error did not come from the Support Debugging Tool code.

Unhandled script exception:

Illegal address for field 'Security Task Category' in script 'AddTaskToRole'. Script terminated.

then a message box with

"Could Not Run File Trigger Script"

Manual manipulation of the MBS Debugger Tasks and Roles would have caused the tool to recreate the edited or deleted records. This would have caused the trigger to fire and the code to fail.

I suspect that the trigger which is causing the problem is an unrestricted table trigger on sySecurityMSTRTask table or sySecurityTempTaskOperations table which is only expecting to be fired when the window syTaskEntry of form sySecurityTaskEntry is open and instead of reading the category from the table it is referencing the window field. The window is not open and so the error is generated. This code needs to be changed to limit the trigger to the form sySecurityTaskEntry or to check the form isopen() before referencing fields in the window.

To identify the cause use the Customisation Status report to look for a table trigger on sySecurityMSTRTask table or sySecurityTempTaskOperations table.

Table triggers cannot assume that they will only be triggered from a specific window especially if they are not restricted to a form when they are registered.

Global procedures (including trigger scripts) should always use isopen() to check a form is open before referencing resources on that form's windows.

I hope this helps you identify the culprit.

Good luck

David

Was this reply helpful? Yes No
Kevin Day 610 on at

Like (0)

Report

My previous question was answered, but since Dave is part of this post, I figured I would just reply to it. At the moment, the reason I am installing this tool is for the Dex.ini settings and hopefully I'll get to use some of the more advanced features in the future.

The most important part of the Dex.ini settings for me are the Last Screen Position ones. Because we are publishing GP through Citrix on 5 load balanced servers, sometimes someone might close GP with the window way over on another screen (dual monitor setup) and the next user launches GP and it crashes because that screen position does not exist for them.

While I was at it, I decided to blank out the "last user" setting (it always just showed the last user who was on that server).

The "last user" setting is working great. But the screen position setting does not seem to be getting reset until after the window actually launches with the old screen position. As if it is changing the settings too late to actually make GP launch with those settings.

Example. I have my DEX.ini configuration in SBT to override the settings as follows (nice and safe).

WindowHeight=400

WindowPosX=150

WindowPosY=90

WindowWidth=600

Last time I left GP, I pulled the window open a little bit more so that it reads

WindowHeight=863

WindowPosX=150

WindowPosY=90

WindowWidth=1627

So before I launch GP, that is what the dex.ini file says.

Then I launch GP and it opens in my last screen position 863,150,90,1627

After GP is loaded I look at my dex.ini file and it is updated with the correct settings. So I guess next time it launches, it would be ok (provided someone else didn't close GP with other settings in the meantime)

WindowHeight=400

WindowPosX=150

WindowPosY=90

WindowWidth=600

This makes me think that maybe this won't work for me after all? Or is there something that I'm missing?

Was this reply helpful? Yes No
Suggested answer

David Musgrave MVP ... 14,093 Most Valuable Professional on at

Like (0)

Report

Hi Kevin

The application window position settings are read by the Dexterity Runtime Engine BEFORE any Dexterity code is executed and are written down AFTER all Dexterity code has finished.

It is impossible for the Support Debugging Tool, or any other Dexterity application to override the settings. The SDT can change the settings using the Dex.ini Configuration window which can help when there are multiple users using the same Dex.ini, but when the last application instance close, it will have the final word.

Build 18 of the SDT introduced a feature which would try to keep all subsequent windows from Dynamics GP inside the visible area of the desktop, but it cannot help with the main application window.

For the main application window, you will probably need to teach users how to use the keyboard and mouse to bring the window back.

blogs.msdn.com/.../where-has-my-microsoft-dynamics-gp-window-gone.aspx

You could also request users leave the main application window on the left hand monitor of dual monitor systems. They can move other windows as desired.

One final option could be to use individual Dex.ini files stored in the users home folders. so that the settings for each user are kept apart. While this does increase the maintenance effort if you need to change a setting, the SDT's Dex.ini Configuration window can automate any setting changes you might need to make.

David

Was this reply helpful? Yes No