Defining Security for Menu Item buttons and Menu buttons

In this post, let us learn how to define access for Menu item button and Menu buttons.
As you are aware, users can define access to a menu item button by mapping them directly to a privilege.
Access can be defined to Output/Display/Action menu items.
In case of Action/Output menu items, access will be either “No Access” or “Delete” access because it is not possible to control the logic defined inside the class/report.
We can bypass the security policy by using XDSService.SetContext which I will explain in detail in my next post.
Since the reports use temporary tables, it is necessary to grant access for those tables as well to the role.
Let us take the standard Privilege  “SalesDeleteProcess” where the access is defined for Action and Display menu items.
Below screenshot speaks about the access to Display menu item.

salesdeletedisplay

Next screenshot shows the access to Action menu item. If you see the standard security objects, access level will be delete for most of Action menu items.

salesdeleteaction

How to grant access to Menu buttons?
I explained how to define access for menu item buttons which seems to be very simple.
Access for menu buttons is little tricky and user needs to make few changes in the form control .
Against each control, there is a property “Needed Permission”.
I shall explain you how to use this in order to set access for menu buttons.
 Let us take an example of “SalesTable” form. In this form, the property for tabpage “TabFinancialDimensionLine” is set “Manual” .
This means , it is users responsibility to define the necessary access for this control ,else it will not be visible for the roles.

Salestable.png

When this property is set, user can drag and drop under Permissions>Forms node of a Privilege.
If this property is not set, drag and drop cannot be performed.
It is also possible to define this set up under Permissions>Forms node of a Role.

menubutton_sales

There is also another way to define the access . Like the same approach which we used in privileges, it can be applied in Permission node of the form.
Drag and drop the control against Read/Delete/Create/Update node and define the access.
In this way, the control will have corresponding access for the roles which have Read/Update/Create/Permission for the form.

permission_salesnode

 

Another tip :
When the Needed Permission is set to “Delete”, it means the control is accessible only for the roles which have Delete access to the object.
It will not be available for the roles which have access less than Delete. User should define the access explictly in such case.
Same applies to other access as well.
Advertisements

About AnithaEswaran

Hello all, Thanks for visiting my blog. I started this blog to share my learning with Ax members . Since I am from technical background, most of my posts would be from X++. Thanks to my mentor and my colleague Romain who guided and helped me in learning many new concepts in Ax. This instilled confidence in me to handle and troubleshoot complex issues. Feedback wrt to my blog entries are most welcome …
This entry was posted in Ax Security, Ax2012, Dynamics Ax. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s