Dynamics Ax and security setup

Microsoft Dynamics Ax has a nice security setup. It hasn't changed much in the last few years, coming from Axapta version 3 to the current version Ax 2009. Basically it comes down to this: You put users together in user groups. Users can be members of multiple user groups. Then you assign security rights to these user groups. There is some more information, like domain setup and record level security, but they are optional.




I would like to focus this post on the rights given to user groups.


This information is collected in the table AccessRightsList.





Now although I am a fan of the security system in Ax, I also believe there is always room for improvement. So here is my case, based on two simple examples.

1) The form LedgerTable.

In this form, access to the control AccountBalance is controlled by the security key LedgerMisc. If you want your users to have access to the account balances, the setup for the security key LedgerMisc is required. But by giving access to this key, you also give access to all the child keys. That's now what you want. So you are forced to turn the parent key (LedgerMisc) on, and it's child keys off. Bad practice in my opinion.

2) Another example for the same scenario, the form Purchtotals.

This form displays the totals for a given purch order. It requires access to the table Common. To be able to use this form, the user must have access to the security key 'AdminTables'. This key has lots of child keys. Certainly you don't want your users to have access rights to all these tables from Admin. So you are forced to turn the parent key (AdminTables) on, and it's child keys off. Again, bad practice in my opinion.

My tips for Microsoft:

1) The inheritance principle is nice. Switch the parent key on, and you get all the child keys. But for a security setup, this is not recommended behaviour. But it would be even better not to assign security keys of the parent type to elements in forms.

2) You promote the use of 'roles' in the program heavily. A lot of marketing material uses these roles, these personas in the Contoso company (the CEO, the clerk, the order processor). Why not deliver a security setup for these various roles? Give the customer the data (security groups with permissions) for these various roles, so the customer doesn't have to start from scratch settting up his security?