In this article we will discuss roles, duties and privileges in Microsoft Dynamics AX 2012. These security levels cover access to single elements, forms, and groups of elements needed to perform a duty. A developer is responsible for defining more granular security levels by setting access on tables and controls in a form, or by associating classes that perform an action with permission.
Each form in the Application Object Tree (AOT) has a permissions node that contains either four or five sub-nodes – Read, Update, Create, Delete and Correct.
- Correct is only displayed if a table in the form has Date Effective data.
- Under these nodes are four additional nodes – Controls, Tables, Server Methods and Associated Forms.
- When a table is added to a form data source, the table is automatically added to the Tables node for each of the Permissions sub-nodes.
- Each of the nodes under the Tables node has an EffectiveAccess property which sets what access is allowed to the table
- The EffectiveAccess property is automatically set based on properties on the data source.
- If the data source property AllowDelete is set to No, the EffectiveAccess property is set to Update.
- If the data source property AllowEdit is set to No, the EffectiveAcces property is set to Read.
To set access for a control in the form, set the Securable property on the control to Yes. The control can then be added to the Controls node under each of the permissions nodes.
Code permissions are a set of custom permissions that are created manually in the AOT under Security > Code Permissions.
- Menu items, especially Action menu items, can use these by setting the LinkedPermissionType property to CodePermission and the LinkedPermissionObject to the name of the code permission.
- Service operations can also use code permissions by setting the Code Permission property under the Service operation > Operation method > Permissions > Associated Code Permissions node.