I spent a good deal of time creating a series of roles to highly limit access to content items depending on the role. I did not want to go through the same exercise again when I moved from the DEV box to the QA box where this access required testing.
To prevent recreation of these roles, I packaged up the roles and installed them from the DEV box to the QA box. When I did, none of the settings I created in DEV carried over to QA. What can I do ?
Since you mention the use of TDS, you can manage the synchronization of all Roles and security on item using features available in TDS. This has the advantage that both Roles and the security becomes part of your solution and can be deployed both locally and across all environments in a consistent manner.
It is possible to serialize any Roles you wish using TDS. You can read more in the TDS documentation, but essentially you enable the manage of Roles in the General tab of the TDS project properties. You can the Sync Sitecore Roles and select the Roles you wish to keep serialized. These Roles will be deployed when you create the update package and install in the upper environments as part of your CI/CD process.
Note: Sitecore stores role definition in the reverse of what you expect - each role stores which other roles inherit from it, so if you inherit a default Sitecore role you must also Sync this role.
As you have mentioned, Sitecore stores the details about permissions on the content item itself. This means that in order promote and deploy this information, you must serialize the items. This leads to a catch-22 situation, esp in a live system when you do not want to overwrite production content.
Luckily, we can deal with this using the Deployment Properties options in TDS. On the properties of the Content Item in the TDS project, set the Item Deployment setting to DeployOnce. This will mean that once an item has been deployed once (i.e. it already exists in the target environment) it will not be overwritten by what you have in source control. This is perfect for content and media items when Production becomes the source of truth.
In order to deploy the security details if they are added or updated, we can set Field Level Deployment to ensure that Security is a field that is always updated regardless of the item deployment setting.
You do not need to include all your Production content in TDS or source control, only the top level items that you have set the permissions on.
You will need to ensure that your Recursive Deploy Action in the Build tab is set to "Ignore Sitecore Items not in the Project" (this is the default) or you have set the appropriate Child item Synchronization setting to ensure that items not in source control are not deleted from Production.
But with this set up you can manage your roles and manage the permissions on your items, have them in source control and ensure that developers and environments go through the correct development workflow.
I wanted to share this answer because it took a bit of discussion and then I needed to develop a strategy. First, I had to realize that security settings as it relates to items are not stored in roles or users. They are stored in the items themselves. Once I understood this, my whole strategy as it relates to packaging and installing these roles and users had to change.
If these content items can be packaged up or controlled through TDS for deployment, then you can deploy or install those items and then package all the roles and users which also need to appear in the higher environments. This is the ideal situation where after all the content items, roles and user items are deployed, everything should link up just fine and you are ready for testing or production usage.
However if you have a mature content tree information architecture whose content section is not maintained through TDS or some other mechanism and packaging up hundreds to thousands of items is out of the question, then while packaging up the roles and users is still a step to perform, you will have to recreate the security settings once those roles and users exist in higher environments. This might be possible using PowerShell but I had a tight time frame and the amount of time I would have invested, I would have it done the hard way in that time. Thankfully all I really needed was one main role that did most of the work and a bunch of child roles inheriting the main role with some minor changes per role.
Before I got started, I did package up the main and children roles and installed them on the higher environment. This will be much faster than creating each one individually again one at a time and you are less likely to forget one.
First, as Sitecore would suggest, I had to update the main role which all my child roles would inherit. What I needed for this main role had to be well documented since I would have to duplicate this process again on each higher environment (such as QA followed by PROD).
Second, I created a process for creating the roles which would inherit the main role (my child roles) and eventually followed a cadence which would allow me to create and even test all the child roles in a pretty quick manner. I would literally assign a test user and re-use it on each child role to ensure that the proper security mechanism met the needed criteria. Since the core database responds immediately, it was not hard to change the role assigned using the User Manager, switch to my Sitecore browser, sign in the same way and take a quick look.
Third, setting up this entire mechanism did require me to build a bunch of items (in this case media library folders) to support these uniquely secure content editors. Since this is new and a relatively small set of items, once I assigned the proper roles or users to each of these folders in DEV, I then packaged them up and installed them on QA. The advantage being that in this specific situation, these folders know about the roles and users I had already installed in its own package. Therefore as a result, this part of the system was completely set with no additional work in the Security Editor to address any access issues.
Those are my thoughts on handling this situation, I hope you found this helpful.
