Security: Past, current and future

When you read the title of this blog post you might think this post is about changes during the lifecycle of Microsoft Dynamics AX 2012. Or maybe it is related to the security framework in older versions (AX 2009), the current version (AX 2012) or the new Microsoft Dynamics AX (aka ‘AX 7’). Well, it’s not. This post will tell you about a standard feature to restrict access on past, current and future records for tables which supports date effective data. It is called “Date effective policies”.

What is date effective data?

In Microsoft Dynamics 2012 a new framework was added to support a more simplified way of controlling data which has several values in points of time. An example is the exchange rates for currencies. For each working day another rate might be applicable. Also you can think of employee data where a person had fulfilled multiple positions during his employment. You can read more (technical) information about valid time state tables on MSDN: Valid Time State Tables and Date Effective Data [AX 2012].

How can we control the date effective policies?

To restrict access on records in Microsoft Dynamics AX 2012, there are two known methods:

• Record level security (RLS) – (will be depreciated in a future release)
• Extensible data security (XDS)

I’m not referring to one of these methods to control the access for past, present and future records. When you open the properties of a security role in Microsoft Dynamics AX, there are three properties which can be changed to control access level for date effective tables.

For all (new) roles the Delete value is the default which will grant full permissions on tables in the selected role. You can change access for each property individually. Assume the Human resource assistant should be restricted to have to view on records which belongs to the past. With the standard settings this person has for example the next records when he views the information on the form Maintain position versions.

You can change the values of the properties to control the access for past, current or future records. For example you might set the PastDataAccess property to NoAccess.

When you save the changes and compile the object, the security for the user having this role will restrict the data based on the property settings of the role. The screenshot below shows you that indeed the record with an end date in the past is not visible anymore.

Additional security notes

1. The restriction for these properties is based on table access for all roles. If there is another role where the user would have access to all records, still all the records will be presented and it looks like your change was not applied. In that scenario, you have to find in which roles the table permissions are granted. You can easily do this analysis if you open the AOT, go to the table, right click the table and choose Add-ins > Security tools > View related security roles.
2. If you have a privilege which is set to have view permissions and one of the properties is set to e.g. Update or Create, the view permission is applied. So it is not possible to override the privilege security to have higher access levels using these date effective properties.
3. A role can contain multiple date effective tables. The setting is applicable for all of these tables. If you need to differentiate, you might need to create multiple roles.
4. You will notice that you can also restrict access on database actions like Create or Update. The user can try to change data as he might have access to update data for future records. When the user tries to save a record which is restricted with a database action, he will get the next error.

5. If you need to work with other definition of dates to control data, you have to use Extendible Data Security. For example, you are not allowed to enter sales orders with a delivery date within one week from today. That should be solved differently. The date effective policies only knows the current date and derived from this the past and the future.
6. Last note for developers: When the date effective policies should be enforces using x++ coding, you need to use the command table::RecordLevelSecurity().

To learn more about date effective tables and how to use it, you can download the whitepaper Using date effective data patterns.

There is more

Usually you can also use the Security roles form to change settings related to the roles. For example you can override permissions or add/remove duties or privileges. Also the setting for the date effective policies can be maintained from this form, but it is not added on the menu strip. You can access these settings when you right click on the security role. The popup menu will list the options like available on the menu, but now also displays the option Date effective policies for role. To be honest, I don’t know why this menu item is not added on the menu itself. Probably the product team forgot to add this option.

When you click the option Date effective policies for role, the next form will be opened. When you change a property and close the form with the button Close or the cross, the changes are saved in the development environment and the changes are effective for new logins.

When you want to discard changes without saving the information, you need to use the Esc button on your keyboard. You will then get the question to save the changes or not.

That’s all for now. Till next time!