Within a previous post I started a series about the Security Development Tool for Microsoft Dynamics AX 2012. I got some positive feedback, so that motivated me to continue with part 2. I saw people using this tool, they think they can easily create or modify roles themselves but at the end they somehow get stuck… So this post is about helping you prevent creating spaghetti.
Probably I should have started in the previous post with this tip.
Like the Security roles form in AX 2012, the Security development tool is interacting with the security objects in the application object tree. The tool uses the same objects and logic as present in the Ax 2012 Security Framework. So before start using this tool, you need to obtain proper knowledge of the Ax 2012 security architecture.
Every Role consists of one or more Duties so a user will have access to the parts of the system needed to perform his tasks. Every Duty contains one or more Privileges which is a set of Securable objects like User interface elements. Mainly menu items are part of a privilege. Per menu item in a privilege it is determined what level of access is granted. E.g. View or Full control. In fact it is also possible to link Privileges directly in a role, but that is not the best practice. The privileges are not supported to be checked in the function Segregation of duties. Only duties are used for this feature.
If you have looked at the Security Development Tool you have noticed that it contains a tree overview of the Main menu with all menu items. When you select a Role in this tool, it will show you the effective access level. So this tool translates the Duties, Privileges and User interface elements in an understandable view.
You can now ask me: “André, it is a nice story. I understand this. I can change it here, so what is your point?”
Well it is easy to select a node (e.g. All vendors) and do a right mouse click, select Set entry points for current node and expanded sub tree items. You can then change the required Access level and apply on an existing privilege.
To do this I have noticed that people are choosing the first menu option to apply it using the first context menu option. The result looks OK. See the next picture:
So now my point: If you had paid attention, the tool mentioned 5 roles. It included the current and 4 other roles. So now you updated multiple roles!
Within the architecture of the Security in AX it is possible and common to reuse privileges and duties. This happened a lot in the standard Roles. So one privilege is used in multiple duties and one duty can be used in multiple roles. So read carefully all details on the Security. You can start reading an article on TechNet: Role-based security in Microsoft Dynamics AX [AX 2012].
Some people thought they figured out that it was possible to select one Role in this part and then it updated only that role. (which is not true!)
Then the person tested the role, selected the next role which should be changed, and so on. This person told me that 10 roles were effectively changed and tested. Then I pointed out that this was not true. I asked to open the first and second role and then proofed that changes were not as they had done. So in fact many permissions were granted, revoked, changed, granted again… and so on. Also as a result I have seen over 500 modified security objects in the AOT.
So now the best way to do this: If you need to modify an existing role take notice of the following best practices:
When you want to apply changes which would result e.g. in a changed privilege, it is possible to use the option Duplicate selection and then remove original. Then in this case AX will duplicate the standard privilege and use the duplicate in the duty. When it is copied you can apply the changes on this copy only which leaves the standard object the same and other roles using the same security artifacts are not affected. This copied privilege can also be reused in several other duties or roles.
Note that if you don’t want to change the standard duty, it is also possible to duplicate the duty with a similar action. In this case first duplicate the Duty and then the Privilege.
If you want to read other tips and tricks on the Security Development Tool, just look on the Kaya Consulting blog, there are other blogs about this subject. Also if you found this blog useful, please share it, so others can learn tips about the Security Development Tool.
That’s all for now. Till next time!