Understanding the export-d365securitydetails.ps1 module.

[carmelopaz0708]

Hi. I just want to get some clarification with this powershell module, export-d365securitydetails.

As I understand it, this module breaks down the SecurityDatabaseCustomizations.xml file into several xml files, all showing any security objects we have in the system (roles, duties, and privileges). I have a bunch of security objects that I need to update in D365 but doing it manually is too tedious, so I thought I could use this function to edit the xml files that were generated and add in my changes (e.g. add new duties and roles by adding the right tags in the file).

Assuming I've made my changes, do I need to run another command to consolidate all of these security objects into one xml file (like the reverse of export-d365securitydetails module)? Is that kind of command available in d365fo.tools? What's the purpose of export-d365securitydetails.ps1 aside from getting a breakdown of all the security objects in D365?

Thank you so much for the help.

[FH-Inway]

Hi. Thanks for raising this interesting idea. I don't think we have the capability you are asking for.

The idea behind Export-D365SecurityDetails is inspired by @ameyer505 's D365FOSecurityConverter. The goal is to break down the .xml file with the security changes made in the UI into its individual security components. A developer can then add those files to a module so that it becomes part of the application.

@ameyer505 , any idea how much pain would it be to combine individual security object files back together in one big file that can imported into the security customizations in the ui? It looks like no transformation of the xml structure is necessary.

I can see the appeal for technical non-developers working on security to be able to do this to enable mass editing of security customizations.

[FH-Inway]

I thought this makes a nice use case for a language model to generate a PowerShell script to do what is asked here. The first attempt by GitHub Copilot was surprisingly good, I only had to convince it to handle the xml namespaces correctly (it is always namespaces with xml, isn't it?). The reassembled test file that I used was identical to the original.
Give it a try: https://gist.github.com/FH-Inway/5fe4a82a9bd42775a1149c2ffe068b11

[ameyer505]

@FH-Inway Thanks for including me and appreciate the effort put into this already! I am impressed Copilot could handle the namespaces when creating the resulting XML (those can get tricky)!

My immediate thought was that yes this was possible as the SecurityDatabaseCustomization.xml file is just a wrapper for the individual security elements that have been customized (this is how the D365FO Security Converter is able to break them a part) so really this is just 're-wrapping' all of those together.

There does need to be some thought on the part of the person using the script on which elements they want to bring into the resulting customization XML from a security management perspective, but the code itself looks to be handling the XML creation correctly.

[carmelopaz0708]

Hey @FH-Inway and @ameyer505 , I really appreciate your helpful insight to my questions. I agree with your points. A script which does the reverse of export-d365securitydetails.ps1 is pretty useful. For my use case specifically, I'm trying to mass edit security privileges. This wouldn't be a problem if it were 10 or 15 privileges, but it becomes a monumental task when I have to edit at least 300 privileges spread out across various duties and roles. The need to expedite this requirement lead me down this rabbit hole and it's how I eventually discovered this project.

I tested the import-d365securitydetails.ps1 script @FH-Inway made in his previous reply and found some major differences. I did this by exporting a new SecurityDatabaseCustomizations.xml file, then running the import script. I didn't make changes to the original file, this is purely to check what was transformed (I did append Customized to the folder with names 'role', 'duty', and 'privilege' in the -InputDirectory parameter to get the import script to work). The import script can't read non-english characters (left is original, right is after import).

This is probably an issue with the export script though. I've noticed this before when testing export-d365securitydetails.ps1.

I've also noticed in my testing that some tags were out of place. VSCode caught some xml tags that seem to have been added after the import script but were removed in the original (and vice versa). I'd assume that since no changes were made to the file then no changes to their location would show up, but that doesn't seem to be the case.

I'll need more testing on this part. Perhaps this has something to do with the way I tested it.

Thank you!

[FH-Inway]

Thanks for testing.

The issue with the non-english characters is most likely an encoding issue. I noticed that the original file is in UTF-8, while the files created by Export-D365SecurityDetails are in UTF-16 LE BOM. PowerShell is infamous for encoding shenanigans. You could try running the commands in a PowerShell 7 console, they made some changes on how encodings are handled there. Otherwise, you would have to change the files to UTF-8. I will look into changing Export-D365SecurityDetails so that it creates UTF-8 files.

The issue with the attributes in the SecurityCustomizationData tag being arranged differently should not be an issue. The XML format does not really care how those arranged. The difference is due to different XML generators use different styles of arranging the elements.

Not sure about the third issue (tags out of place), maybe you can provide more details on that? If it is just about the order in which the security objects appear in the file, that should not matter. The XML specification has no requirements about the order of elements, so different generators use different logic to arrange them.
If possible, provide the files you used for testing (you can also send them to me directly if they contain private information - my contact info is in my profile).

[carmelopaz0708]

Thank you for the clarification. I wasn't aware with Powershell's encoding shenanigans. I tested the export/import scripts again but in Powershell 7 and I'm happy to report that the non-english characters are handled correctly. Left-side is original (before export/import) while right-side is after the file has been exported/imported.

As for the xml tags being "out-of-place", I was referring to the tags being encoded in the incorrect lines (as compared to the original). In the example above, <_x003C_NewObjectList_x003E_k__BackingField> in the original is at line 8, while after transformation, the same tag is now in line 31. As you said in your previous reply, this is a non-issue, since XML generators use different styles for arranging the elements. As long as the same, exact tags are there (and in the correct hierarchy), then we should be good. And after looking closely at the differences, the XML tags are still the same and in the correct hierarchy. Thank you for clearing that up for me.

It would be fair to assume then that after exporting/importing the same SecurityDatabaseCustomizations.xml, I can import that transformed file back into Security Configurations without issue. I tested this scenario, following the steps outlined below.

1. In Security Configurations, create the custom security objects (roles, duties, and preferences).
2. Export the file to obtain SecurityDatabaseCustomizations.xml.
3. In Security Configurations, navigate to Data > Remove Customizations.
4. Run Export-D365SecurityDetails on SecurityDatabaseCustomizations.xml.
5. Open output directory and append "Customized" to all existing folders with string "AxSec%". (This is to simulate that we've customized the file).
6. Run Import-D365SecurityDetails
7. Import the new SecurityDatabaseCustomizations.xml file to Security Configurations.

My issue is at step 7. It seems D365 can't find the reference to the object identifier.

This is still the same file exported from D365 and passed through the export/import scripts. If I clear the customizations in D365 then import the original SecurityDatabaseCustomizations.xml file, I don't get a reference issue.

I'm not sure why this is an issue since the same, exact, tags are present in both files.

I'd be happy to share the files I used for testing this scenario. Please check out the attached files. I'll be testing other scenarios out as well.

TestSecurityScripts.zip

[carmelopaz0708]

Quick edit on my previous comment. It seems the steps I've outlined in my previous reply were inducing the error. I tested the same steps but appended the folder names with "New" (to simulate new security objects. Makes sense since these objects don't exist in D365 yet), and the transformed SecurityDatabaseCustomizations.xml file was successfully imported into D365.

That said, I think the import script has some important limitations. For example, since the Name tag uses a random string (this is auto generated in Security Configurations), we can't just use our own value for any new security objects we create in the file. This means we can either use the import script to only modify existing security objects (like change the Create and Deny tags in privileges) or clear the front-end of all customizations prior to import (we'll still need to export the original SecurityDatabaseCustomizations.xml, then append "New" to all folders in the import script's directory. And we'll have to add the custom security objects in D365 prior to import to generate their own Name tags).

Either way, at least we have an easier option to edit security objects programmatically.

[FH-Inway]

Thank you for the detailed comments. Glad it already is of value to you, even with the limitations.

I will do some testing as well, I think it should be possible to mix new and customized objects.

For the Name tag, you can try the New-Guid command to generate a value for that field.