We have 12 security roles in our VSA, from level 0 that allows an admin assistant or accounting team member to run reports, to level 9 that allows Master-like access (but blocks agent administration). Level 1 and 2 are for the engineers that allow agent management. There are 4 level 5 "specialist" roles that permit administration of specific VSA functions (patching, Auth-Anvil, and such), and two level 9 roles, one that allows security management. We then have 3 customer-access roles - Remote Desktop, L1, and L2 with increasing access levels.

We have two Dev VSA platforms, one on-prem and one in SaaS, and two prod VSA platforms. We develop in Dev On-Prem, test in Dev SaaS, and then deploy to Prod. Each VSA platform has the same configuration, right down to the roles and role names.

I have nearly 300 views, about half for either MSP-only or general use (all users, including clients), and the other half are used for policy control. As views are created, they are shared appropriately. The MSP-only views get the 9 MSP roles; the General Use roles get 9 MSP and 3 Customer roles, and the policy control views have no additional access.

Here's the issue:

• I export the views from Dev and import into any other platform, and none of the share settings are preserved. Well, even though the Role names are the same, the RoleID values are different, so I accept that these can't be translated. Probably some security concept, which is odd because any change to VSA (product add) grants full access to all roles, but hey, I digress..
• To insure that the role IDs and Names match the target system, I create a fake view on the target system, assign all custom roles to it, and export it. The resulting XML file contains the Role Name and Role ID values from the target. I extract these into a configuration file. I run a script on the exported XML file that finds each Role Name, looks up the target value in the config file, and replaces the Role ID with that from the target system. Thus, all Role Names and Role IDs should match the target, and the import should work.
  Alas, it does not. If the roles were not imported at all, I'd figure that security settings were ignored during import of the views. This is not the case, in fact, SOME of the roles are imported properly, while the rest are ignored. Hmm, I must be overlooking a setting somewhere.. let's try something else.
• I create a view, assign ALL the custom roles and export the view. I delete the view and import the just-exported view back into VSA. Again, only SOME of the roles are imported back into the original machine. I opened a support ticket, because this is clearly a bug..

The support engineer replicates this issue and escalates to engineering. Engineering says "this is by design" and I should open a Feature Request. I decline and ask to escalate. I think that if this was "by design" that either ALL or NONE of the security roles would be imported, but having SOME imported is not by design. If that were the case, how would the decision be made as to which role is imported and which is excluded? Digital dice roll, perhaps? I've gone round and round with this for the past month in support, PSE, and engineering, so - I figure I'd put it to the community:

            Is this a BUG or BY DESIGN??

Let me know your thoughts.

Glenn