Some time ago I encountered an issue where users in AX 2012 were able to modify records even when the security role should have read rights only. More people have experienced this issue and others will do in future. This post will tell you about the cause and how to solve it in your environment.
What is the issue?
Suppose you have assigned some users to a role where they are able to view the main accounts and/or dimension values. You are probably proud because you have created the role yourself. Then a user notices that he is able to change the name of the main account or dimension values. This was not how this role was meant to be. To solve the problem you start evaluating the role. Stop searching in this role as it is probably not caused by this role, but the system user role.
Out of the box the System user role has access levels granted to tables to be able to handle some basic functionality like using Alerts. Also the role should ensure you have read access to many tables related to e.g. main accounts, financial dimensions and account structure setup to be able to use functionality which reads e.g. setup related to inventory posting. Some tables do have higher access levels which is really needed, but there are also some tables with e.g. create access level which will cause the issue as mentioned above.
When you open the Security roles form (System administration > Security), you can select the System user role and click the button Override permissions. You will notice there are many tables having view access rights, but also some with higher permissions.
There are some tables within this role which causes the user has edit rights in stead of view only:
You can solve the issue by overriding the permissions. Select each table and clear the Do not override field. Then set the access level to View.
These changes will cause the access on forms are correct. I don’t know the reason of the higher access levels. Until now I have not seen any other feature impacted that was not working anymore. This is no guarantee that everything is still working as expected in each module for every single environment. So you can use this as guideline, but please test if all your process are working without other interruptions caused by this change.
There is more
Override of the permissions causes the security role to be changed in Dynamics AX. If you are familiar with the Dynamics AX development environment you can go to the security role and also apply these changes via the AOT.
The privilege DimensionEssentials has the detailed table permissions which causes the access levels set too high.
That’s all for now. Till next time!