From the Microsoft Dynamics GP Application Level Security Series.
Microsoft Dynamics GP version 10.0 introduces a new pessimistic task and role based security model. This model is defined in the following way:
Note: Operations may be assigned to multiple Security Tasks and Security Tasks may be assigned to multiple Security Roles.
In the situation when a system administrator knows which window (or report) they wish to grant access to a user, but does not know what Security Tasks or Security Roles are associated with the window, there is no simple method to obtain this information from within the application. It would be possible to scroll through each Security Task on the Security Task Setup window (Microsoft Dynamics GP >> Tools >> Setup >> System >> Security Tasks) and check if the window is selected, but this is time consuming. The Print Operation Access report which can be printed after selecting the window will show which users have access to the window, but not how that access was obtained based on the Security Roles and Security Tasks.
To obtain the data we will use a new Security Resource Descriptions table (Technical Name: syCurrentResources (SY09400) table) which was added to v10.0 to create a SQL Query to obtain the information. This table is initially empty, but can be populated by running the Clear Data File Maintenance process on it. The system will then rebuild the contents based on the current installed dictionaries.
Below are the steps to populate the Security Resource Descriptions table:
Now that the Security Resource Descriptions table has been populated we can use it in a SQL Query from SQL Query Analyzer (SQL Server 2000) or SQL Server Management (SQL Server 2005). The Query below will display the Security Roles and Security Tasks associated with a specific window or report as selected by changing the Display Name on the last line of the query.
SELECT ISNULL(A.SECURITYROLEID,'') AS SECURITYROLEID, ISNULL(M.SECURITYROLENAME,'') AS SECURITYROLENAME, --ISNULL(M.SECURITYROLEDESC,'') AS SECURITYROLEDESC, ISNULL(O.SECURITYTASKID,'') AS SECURITYTASKID, ISNULL(T.SECURITYTASKNAME,'') AS SECURITYTASKNAME, --ISNULL(T.SECURITYTASKDESC,'') AS SECURITYTASKDESC, R.PRODNAME, R.TYPESTR, R.DSPLNAME, R.RESTECHNAME, R.DICTID, R.SECRESTYPE, R.SECURITYIDFROM DYNAMICS.dbo.SY09400 RFULL JOIN DYNAMICS.dbo.SY10700 O ON R.DICTID = O.DICTID AND O.SECRESTYPE = R.SECRESTYPE AND O.SECURITYID = R.SECURITYIDFULL JOIN DYNAMICS.dbo.SY09000 T ON T.SECURITYTASKID = O.SECURITYTASKIDFULL JOIN DYNAMICS.dbo.SY10600 A ON A.SECURITYTASKID = T.SECURITYTASKIDFULL JOIN DYNAMICS.dbo.SY09100 M ON M.SECURITYROLEID = A.SECURITYROLEIDWHERE R.DSPLNAME = '<Display_Name>'
Note: The <Display_Name> placeholder represents the actual display name. For example, the display name may be "Sales Transaction Entry".Below are the example results based on a default installation for 'Sales Transaction Entry':
If there are no Security Roles assigned to the Security Tasks, they will show as blank. If there are no Security Tasks assigned to the Operation, they will also show as blank.
Security Table Information
Security Operations for a Security Task are stored in table sySecurityAssignTaskOperations (SY10700).Security Tasks are defined in table sySecurityMSTRTask (SY09000).
Security Tasks for a Security Role are stored in table sySecurityAssignTaskRole (SY10600).Security Roles are defined in table sySecurityMSTRRole (SY09100).
Security Roles for a User and Company combination are stored in table sySecurityAssignUserRole (SY10500).
Also see the following post for how to use the Support Debugging Tool for Microsoft Dynamics GP to achieve the same results:
How to identify the Security Tasks and Security Roles using the Support Debugging Tool
Edit: Build 10 of the Support Debugging Tool now includes a Security Information window which can be opened from the Security Profiler and Resource Information windows. This window will display the Security Tasks and Security Roles associated with the select resource and provide easy navigation to the security windows to make changes if desired. Just right click and select Security Information to open the window. For more information see Support Debugging Tool Build 10 released.
Ref: Portions from KB 951229
17-Nov-2008: Add link to Support Debugging Tool version of the post.
15-Jan-2009: Add details of new Security Info window in Support Debugging Tool build 10.
30-Aug-2010: Added link to Update: How to identify the Security Tasks and Security Roles using the Support Debugging Tool.
PingBack from http://blogs.msdn.com/developingfordynamicsgp/archive/2008/11/10/microsoft-dynamics-gp-application-level-security-series.aspx
Over on Developing for Dynamics GP, David Musgrave continues his killer series on Security in Dynamics
This has been up 2 days and I'm already using it at a client. Thanks David!
From the Microsoft Dynamics GP Application Level Security Series . In the previous post, How to identify
From the Microsoft Dynamics GP Application Level Security Series . When access is denied by the application
One of the great things about blogging is the ability to inform and educate partners and customers on
Posting from the Dynamics GP Blogster
Thank you for these queries. They were immediately useful for a number of clients.
Have you looked at how to identify Smartlist Objects? They do not show up in the query results. I think it has something to do with the Security Resource Type in SY10700 but am not sure.
Thank you again.
Wow! I have needed this for a long time! Thank you so much. This is the sort of little thing that Microsoft always leaves out that sometimes renders supporting GP so difficult!
The windows for the third-party application I developed have blank fields for security role id, role name, task id and task name. How do I correct that?
I have a question for you back - what is the difference between YOUR app and a GP 3rd party such as Field Service? And from there, I assume this all works OK for Field Service?
How does one run the referenced Print Operation Access report?
From the Security Tasks window (Microsoft Dynamics GP >> Tools >> Setup >> System >> Security Tasks), there is a "Print Operation Access" button on the bottom left of the window.
Just select an Operation on the Access List and then click the button to see which users have access to that window.
As mentioned, this does not show "how" the user got access. You can use the Support Debugging Tool to show which Security Tasks and Security Roles enabled the user(s) to get access to a particular operation.
When setting up GP10 is it okay to modify existing roles or for upgrade reasons should we copy the existing role say AP Clerk and then add things as need to that existing role as needed for our client AP Clerk needs? Am worried about future upgrades and reseting what is in the core role. What is the best practice?
Yes it is ok to modify the roles. Best Practice for upgrades? That is hard to say - my first thought would be that you would probably be ok during any kind of upgrade. I doubt that we would actually go in and remove all the roles and then recreate them again. Just because that would be potentially destroying user data at that point.
Notice I said "doubt" and not "we wouldn't ever" do that. I just doubt it unless there wasn't any other option for whatever dev was trying to accomplish.
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.