One thing I’ve been asked about numerous times and has caused confusion while using the user interface to set up security is some interesting behavior regarding objects showing up in the ‘Unpublished Objects’ area when no changes are made by the user.

The Scenario

A typical scenario is as follows:

• User goes to System Administration -> Security Configuration -> Privileges (and notices there is no objects within Unpublished Objects)
• Goes to a specific privilege -> Opens an object type -> Add a reference
• User makes no change and clicks ‘Cancel’
• User notices there are now objects within Unpublished Objects and wonders (correctly) what has changed

I captured this behavior below, in this example scenario I am using the ‘Maintain Vendors’ privilege for testing:

What’s Happening in the Database?

If we first look at the SecurityPrivilegeCustomizeDiskObject table we can see an entry here for our test privilege. If we compare the Data and OriginalDiskData fields they are identical, so the security framework thinks there was a change but correctly records that no change was made to the privilege.

And now if we look at the SecurityUnpublishedObjects table, we see the VendTableMaintain privilege entry as well as a number of roles that are showing up. However there is no corresponding entry in the SecurityRoleCustomizeDiskObject for these objects, so the security framework doesn’t think a change was made for these roles but for some reason the Unpublished Objects area is still reporting that there was.

So I dug a little deeper, using the Fastpath Security Designer tool I helped build. In that tool we have a feature called ‘Affected Objects’ which allows a user to see what objects in the security hierarchy would be affected if you made a change to that current object. So if we run this for the ‘Maintain Vendors’ privilege, we would be able to see all duties, roles, and users that would be affected if you were to make a change it.

After running this report you can see something interesting, the roles that this privilege is assigned to are the ones that are showing up in the Unpublished Objects area. So these are the roles that would be affected if you made a change to the ‘Maintain Vendors’ privilege.

My guess is that, some code during the initialization of the ‘Add Reference’ call is signaling/flagging that these roles and privilege are going to change and does not check whether a change is actually occurring. So when the user cancels out of it the framework is left to clean up the best it can.

Solution Options

The solution for this is one of two options:

• Publish the ‘changes’ to the Roles/Privileges (there is no current effect to security by doing so)
• Remove the entries manually from the tables I listed above

The downside of the first option is that you now have an entry in the security delta for that privilege, so for example if you were to make a change to ‘Maintain Vendors’ privilege in the AOT going forward it would not be reflected in your security because you published that privilege’s security in the user interface previously and it would override it.

Note: I describe this process in much more detail in Settings Up Security in D365FO – Part I – From the User Interface

The downside of the second option is that you have to have access to SQL and have the knowledge to go in and remove the correct rows and this process is unavailable in a production instance.

This issue appears to affect all versions of D365FO (I tested this against a PU23 8.1.3 environment) so I wanted to give everyone a heads up that it is something that you will have to keep in mind while developing security.