Why you should be careful if you want to change layer of security roles in AX2012.

If you have any customized security roles in AX2012 at your chosen layer let’s say on USR Layer and you are looking forward to take these security roles to another Layer let’s say to CUS layer, this can be harmful. It can be harmful in the sense of losing all “Overridden Permissions”. As you might be aware that on each security role you can override permissions using standard AX; doing so creates reference objects under selected security role.

Imagine you had RoleABC on USR and you followed following steps to change its layer.

1)     You exported the RoleABC from USR Layer.

2)    Imported the role into CUS Layer.

3)    Deleted the role from USR Layer.

Here is interesting and dangerous bit, which I found nowhere documented. It will lose all overridden permissions for that security role. Don’t believe it..? Try yourself.

What happens technically?

In the Model store database, there is a table named as [ModelSecurityPermission]. This table saves layer of each overridden permission for a security role. The security role is represented by a column named as OWNERHANDLE in the table (ModelSecurityPermission). Initially when you override security role permissions in any layer, the layer is saved in table ModelSecurityPermission in the column named OWNERLAYER.

Now when you performed step#2 from above list of steps, you may be expecting that layer information will also get updated in the column OWNERLAYER for overridden permissions under that security role. BUT that would not happen and when you will perform the step#3, you will lose all overridden permissions. To avoid this situation

1)     Either don’t try to change the layer of security roles, and let those running on any layer (where they were originally changed; permissions overridden)

Or

2)    Write update script to update references in table ModelSecurityPermission. This script should update OWNERLAYER column for each security role, for which you are changing the layer. The script can be run after step#2 and before step#3.

Choose the better option. If you have people who can TEST WELL, go for #2, otherwise don’t take a risk to lose objects.

As I said previously this is documented nowhere (I haven’t found, at least).