Finding a security privilege in AX 2012

Been working on a couple of security issues today. The requirements were pretty typical – we needed to find the security duty or privilege which unlocks a particular feature. This example is taken from a Microsoft Dynamics Community forum post – but it exactly parallels a help desk call I answered this morning.

The example is the ‘Post’ button on the Item arrival journal – but the process is the same for any form or menu option or button.

You can find out which security duty you need to assign your user’s role in two ways.

First the old-fashioned way. You need to open the form’s design in the AOT. The simplest way to do that is to Right-click > Personalise in the form, then on the Information tab click ‘Edit’:


The system opens the AOT and you can see the form design:


Open the design tree until you locate the button you’re interested in and check the Properties for the button. The properties show me that this is an Action menu item, called WMSJournalPost.

Close the form design, and in the main AOT tree find that particular item. Then Right-click > Add-ins > Security tools > View related security roles:


Then the system displays all the information that you want:


When we’re setting up security if we want to make changes, we like to leave the standard roles in the system for reference, so we create new roles and add (or remove) duties to customise.

That’s done in the AOT too – so we treat Security roles just like any other customisation. We decide which layer we’re working in (var or cus), then we prepare and test them in a UAT environment and deploy them into the PROD environment.

So the other way of doing this is to use the Security Development Tool.

You’ll need to cosy up to a developer to download and install this, and you should not deploy this into a production system because it’ll slow the system down, but it’s a useful add-in to your UAT or TEST systems.

Before you use the Security development tool, log into the appropriate layer. You’re using a form but storing changes in the AOT.

Open the menu item Systems administration > Setup > Security > Security entry point permissions. You’ll have to wait a few seconds while the form loads itself:

When you can. Click ‘Load additional metadata’, again there’s a short wait, then you can select a security role, and within the menu tree you can navigate to menu option:

In my case, I needed to get a bit deeper into the tree:


Right-click ‘Discover submenu items’ gives me the options I’m looking for:


Now, when I select the menu options I can see immediately whether the role I selected has access to the option.

Adding the duty to the role is nice and simple:


Right-click > ‘Reference duty’ shows this form:


Note the ‘Add to role’ button on the bottom of the form – couldn’t be much simpler could it?

Just remember that although the Security development tool lets you customise your security roles they’re still stored in the AOT, and they have to be deployed, ‘cos you’re not using the security development tool in your production system.