I previously wrote about how to create a read only role for D365FO via the AOT. A lot of users thought my use of the term ‘easy’ in the title was misleading, which I can’t really argue with, It does get slightly technical on how to create it. So I thought it might be a good idea to make this process a little more user friendly and make a read only role that anyone could import into their D365FO environment via the user interface.
To create a read only role based on the out of box objects that any customer can import into their environment. This could then be modified if the user has any custom objects or needed to make other security changes to it. The read only role should grant ‘Read’ access to all out of box menu item displays and menu item outputs in the system.
One thing to note here is that while creating/modifying security in the AOT is a different process than creating/modifying security in the user interface, both processes generate XML that D365FO then consumes. It also just so happens that this XML syntax is basically identical (there are some slight differences that I will note here but overall the security XML is the same whether its created in the user interface or the AOT the only difference is where it is stored at).
I started my process by mimicking the process for creating my read only AOT role and creating a privilege that I could assign all menu item displays and menu item outputs to. I did not assign any access to the objects but instead just built the solution. I was then able to go into the AxSecurityPrivilege folder and find the generated XML file:
This is great as it generates a lot of the XML we need, but there is no access set for these objects (every access shows Unset for each object) and there is no easy way to set Read access to every object in the AOT. Luckily we can use a little regular expression magic within Notepad++ (or any other text editor that allows for complex Find/Replace):
We are going to find this string: ‘</Name>\r\n\s*<ObjectName>’
And replace it with this string: ‘</Name>\r\n <Grant>\r\n <Read>Allow</Read>\r\n </Grant>\r\n <ObjectName>’
Note: Select between the apostrophes. The reason these strings look so unusual is to match the XML formatting.
By doing this we can generate this XML:
Now we have the privilege piece done, we need to get this data into the format needed for the security import into the Security Configuration area of the user interface. To do this I first took a blank environment and exported the security data without any customizations just to see the format of the file. While this may look scary it basically it really is just a combination of the role, duty, and privilege security changes in an XML format.
I then took the read only privilege we created above and placed it into the privilege section of the XML and a role that referenced the privilege in the role section.
And viola! We have a valid read only role that’s ready to import!
But the only way to validate this is to test by importing this into a D365FO environment:
And just to validate if we go and look at the View Permissions for this role we can see we successfully have Read access to all objects:
I Don’t Want to Go Through All of This, Where Can We Get The File?
I have provided read only role XML created above here for download: Read Only Role
But keep the following in mind:
- This file is delivered ‘as is’, you accept the responsibility for maintaining this going forward
- If you have custom objects that you want to grant access to you may need to modify this role further
- If you want to rename the privilege or role you can do so by modifying the XML
- This role was created on a 10.0.20 version of D365FO, as newer versions come out new objects may be added that would have to be added to this role
Hopefully this post helps and shows how you can help meet this requirement. Feel free to reach out with any questions.
Great post. I always get this asked on all implementations and I used to direct this at the developers. Thanks for sharing!
This is awesome. I love the idea to convert the AOT version to the data version, as the AOT version requires to refer all the modules, which are really what we want. I do find some exceptional cases though. We still need to fine-tune the role further with more testing.
1. Some tables require explicitly assigning the permission under the privilege (I had found two tables during my testing. To fix this issue we can add the table permission in the security configuration form)
2. If a button/dialog button on a form has no access level control, the read-only role can press those buttons (these are bugs on standard forms. It cannot be fixed unless we do a code changes)
3. Some menu items can perform some action even with read-only access (for example, Transfer fixed assess button on Fixed asset form. To fix this, you will need to find the related menu item and remove it from the Read Only Privilege.)
Not sure if this is something new to D365 or not (I’m fairly new to working in D365 vs 2012), but within the UI you can add all menu items to a privilege and also set the “Read” to Grant at the same time (for all items that you are adding). Is there something I’m missing vs using the file you created?
Good find! This selection was not available when I created this post initially. I will have to create an update to show how easy this is now. Thanks for letting me know!
Here is the blog post about this new process for generating a read only role: https://alexdmeyer.com/2022/06/20/an-update-to-creating-a-read-only-role-for-d365fo-user-interface/