AX 2012 - Hiding a form control without code

With Microsoft Dynamics AX 2012, the whole concept of Model more and code less is in full affect. The idea behind modeling, is that you cut down on the need to create custom code, to achieve needs. This is a great overall concept, and we are seeing this in Workflows, and well as Security.



So taking this to heart, and running with it, lets say you have a request to hide a form control, based on some context. Lets pick a functional one, in that we don't want users, who have read only access to a form, to see a specific form control.

In the past, real simple steps could be taking to do this, and a popular way of handling such a request, would be to (a) Make sure the control had AutoDeclaration set to yes, and (b) override the init() method of the form, and work with the forms .visible() property. This would be based on either, say the company, or a security key in the pre-AX 2012 days.

This however has changed with AX 2012, and we can achieve this need, without any code actually. How you may ask? Well check out the following Microsoft resource: Security Permissions Properties for a Form [AX 2012]

"To see a particular control on a form, the user must have a permission to the control that is at least as strong as the permission the control requires.
For example, suppose a control has its NeededPermission property set to Update. A user who has only Read permission does not see the control on the form. But the control is visible to another user who has Update or Delete permission to the control."

So lets explain this a little bit then, shall we? To start, we have a need Permissions node that lives under the form objects now.



With this, we see, as mentioned in the above resource, the Read, Update, Create and Delete Permission nodes. Each of this are in order of weakest to strongest security. In that, if a user has a privilege that enables them to have Read access to the form, and then control had the needed permission of Update, the user Would not see the control on the form. Since this is the desired scope, then we understand how we can relate privilege's to NeededPermission.

When looking under these nodes, you would not drag or drop controls under each. Nor do you create new elements, under the Controls node. If, we want to take a control, and have it's NeededPermission to be set as Update, then we must go to that Control, open the properties, and set the NeededPermission value as so.



On saving of this property change, we can now see that under the Update node of the Forms Permissions, contained within the Controls section, we see now our 'Control2' has appeared.



Now through proper security setup, when users only have Read level permissions to our form, they will not see the Control2, form control. So we have used security modeling aspects of AX 2012, and not code, to enable the visibility of a control on a form. Pretty powerful huh?

Well that's all for this post, I hope this helps someone out. Keep checking back as we continue to dive more and more into AX 2012.

Till next time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"