Security how-to: Disable change of session date for users

In the past, I already wrote a blog for awareness about the session date in Microsoft Dynamics. When you read this blog, you will learn about the purpose, but also that there are two options to change the session date in the standard application. However this is a great and helpful feature, some organizations might want to lock this option to prevent incorrect usage of this option and ensure people will post in the most recent period by default unless they would need to backdate a transaction. In this blog, I will demonstrate how to disable the option for all or particular end users.

Session date

The most obvious option to change the session date by end users is using the calendar control on the default dashboard. When someone clicks on a date, a confirmation box is prompted which will change the session date in memory.

There is no visualization on pages where users can enter transactions, like journal lines. The user might have set an incorrect date, might have forgotten which date he entered, or refreshed the browser which will reset the session date as it will then create a new session for the user. For that purpose, I did create a small tool where the session date can be pinned in the Dynamics 365 application. Still, you might want to lock the option for users to change it.

When someone will have an initial look at the page design of the default dashboard, he will learn that technically a container control is used which will show an extensible control. There is no form part used that will be managed by a menu item that can be secured, so initially, you would think disabling the calendar control would need a customization.

When you look at the second option for changing the session date and time (Common menu), you will notice this is managed via a menu item called SystemDate. When deep diving into the technical implementation of the calendar control and the option to change the session date, this same securable object is also considered in coding to show the confirmation box or not.

Security implementation

There are various ways to manage the access level of the Session date and time form and together with this also the calendar control. Full permissions for the session date are part of the System user role. I would not suggest changing the contents of this role. For sure not if there should be a differentiation to manage which users should not or would be able to change the session date in the same environment.

One option would be creating a new privilege with deny permissions for the Session date. You can then link this to an existing or new role directly or via a duty. As you can see in the example below, I denied all access. When users will get the deny permissions assigned via a security role, it will remove the option for the session date and time in the common menu. Also, it will not act anymore on the date selection in the calendar control.

There is more…

Initially, when I looked at the coding, I thought that still having the read access and deny update, create, and delete would be sufficient. As you can see in the screenshot below, permissions are checked for either delete, add and edit rights and not the option view. However, the method sysDictMenu.rights() only returns NoAccess or Delete. In case of view permissions the value Delete is returned otherwise NoAccess. When view permissions are granted, then still on the Session date and time form the user would be able to change the session date. For this reason, the most easy way is denying all access to this menu item.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!