Andre from Kaya Consulting has written a series of excellent articles on AX 2012 Security Development: here is Part 4:
After writing 3 blogs with tips on the Security Development Tool, I do have more tips to share. This time I will talk about the option Mark form controls. I will explain this feature as well as how to get this working in AX 2012 R2 and R3. Also a nice tip is to expand this with other access levels.
Tip: Mark form controls
When you look at the Security development tool form, you will notice a menu button called Mark form controls. By default this one is turn off. What is exactly this button doing and how can you benefit from it? The documentation on technet does not mention too much about the feature to Mark form controls. The only explanation is literally: “Enable this function to display menu items that have NoAccess permission on forms.”
Well this feature can be used to look at several form in the current AX client and see which menu items on forms are not accessible within a certain role. You can e.g. see which buttons are hidden for the Accounts payable manager on the customer form. How to do this?
Select a role in the Name field. Then click the button Mark form controls to turn on the feature. (You can also first enable the option prior to selecting a role)
When you do this the first time, you will get an information box stating it will create some additional code (in the current layer and model) to be able to hook some form controls.
Click Yes to enable this feature. In the next tip I will show you which code was added with this confirmation.
When you then open a list page or form with menu buttons, the options which do have no access within the selected role, will be marked with the Prohibitory sign. So when you are developing a role, you can see from the Security development tool form which menu items are accessible, but with this feature you can also validate the menu buttons on forms.
So this is a nice feature, but it does not work out of the box in Microsoft Dynamics AX 2012 R2 and R3. This will bring us to my next tip:
Tip: How to enable the Mark form controls feature in R2 and R3
As mentioned the Mark form controls is working for the RTM version of AX 2012, but not AX 2012 R2 and R3. This is because the kernel acts different between the various versions. Note that probably some kernel versions from the RTM version also will cause the same problem, but I’m not aware of all hotfixes and kernel versions. In this case also read this tip how to solve this.
As seen in the previous tip, AX will add some code on a system class which manages form interactions. The next coding is added:
The static method being called will take care of changing the resource so the prohibitory sign will be shown. It seems like after the initialization of the form in AX 2o12 R2 and R3 the standard resources are loaded. So we have to move this code to another method of the class SysSetupFormRun to have it fixed.
If you browse in the AOT to the SysSetupFormRun class, you can create a new override method ‘Run‘. Use the next x++ coding in the new method:
Save and compile the class.
Note that the Security development tool checks if the line still exists in the Init method. You can be smart and change this logic to create this method or disable the check.
Now also in Ax 2012 R2 and R3 the Mark form control feature is working.
Tip: Expand the Mark form controls feature
I think the Mark form controls feature is useful. When looking at the menu items that are available within the selected role I would like to know which menu items do have full access or are e.g. read only. It is possible to change the FormRunHook method to have this feature behave a bit different. The next example will show you how to add a Loop resource on menu items which do have access level View.
In the AOT locate the class SysSecEntryPointManager and open the method FormRunHook in the x++ editor. Then add the code which is marked in the next screen shot:
Save and compile the class.
When you then open a list page or form you will now have both the Prohibitory and Loop sign on the form controls. Pretty neat?
So you now can see the difference between menu items without access permissions, with view and full access. Note that the Edit button now illustrates that it will only open the details form with View access rights. So in fact the selected role is not able to change the details of the vendors.