I was tasked with setting up the security settings which was needed for the content editors providing the content of the Sitecore site we are working on. While Sitecore provides an author role, it does not provide an editor role which allows a content editor to edit existing items and well as add new items and it does not provide publishing capability for those editors.
It was not very difficult to set this up but it is beneficial to have a road map on how to set up this access for content editors. To make the process easier for the next Sitecore security administrator, I am documenting this road map. Through this process I was able to set-up content editor role accounts which not only allows a content editorial to add new content but also allows them to edit existing content and to publish content successfully so it is available to customers of that site.
As I discuss the road map I took, I want to make clear that I will not be discussing all the ins and outs of using Sitecore’s security tools but focusing on only the specific aspects of the tools which I used to complete the exercise of creating a successful content editor role.
Creating the Editor Role
The first step I took was to create a new editor role which all my editors would inherit. Be careful when you name the role only because a role cannot be renamed once you start using that role to establish the access of actual users. This new role was created using Sitecore’s Role Manager security tool. If you click the New command button, the following window appears where the role would be created.
Once created, the security administrator would add the roles it would inherit using the Member Of command shown below while the newly created role is selected.
The roles Inherited by this new content editor role which provides the needed security access is shown below.
The new content editor role had to inherit the Author role for the basic edit rights that an author would require to create content. The Designer role is needed to allow proper use of the Experience Editor by an editor. They would also need access to the Sitecore Client Publishing role to allow them to publish content to the live Sitecore site so that customers can access newly created or edited content.
These inherited roles provide most of the basics but it does not cover the ability for a content editor to edit existing items in the content tree which they would need to maintain existing content as well as adding new content.
Using the Access Viewer to Assign Editing Access
There is not a pre-defined role in Sitecore 8 which provides editing access to existing items in Sitecore across the board, so a security administrator has to use Sitecore’s other security tools to provide that access. With that being the case, I used the Access Viewer. I opened the Access Viewer and selected the new content editor role I created in the previous section. I could have used the Security Editor, another Sitecore security tool which is used to change security settings on a role or user, but I used the Access Viewer because I would be able to tell immediately if the change I intended actually took place using its security access grid. The immediate impact of a security access change to a role or user cannot be monitored using the Security Editor. The discussion below will assume that the audience has worked with Sitecore’s security tools and will not cover all details of that process but will cover specific instances of how those tools were used for the intended effect to content editors.
For example, I selected the Home item of the Sitecore site and adjusted the security access for the content editors in the following manner shown in the image below using the Assign command in the ribbon. Note that the selected role in the image below, is the one used for the content editors in the environment I am using for this discussion. I allowed the Home item to be editable so that content like the presentation details of that item can be changed (note that the editors cannot rename or delete that item). The descendants of the Home item, however, can be edited, created, deleted, and renamed by those same editors. Sitecore items inherit the security access of its parents so not only will this change affect the immediate child items of the Home item but all descendants of the Home item. Also, by setting it up this way I was able to affect the needed access to these items for content editors through the use of one item rather than being forced to edit the security access of each item underneath the Home item one at a time. This change would also impact any newly created items as long as they are created underneath that Home item.
I would treat other parts of the content tree under /sitecore/content which require similar access by the content editors in the same way. Below is an example of the settings I used for a Shared Content folder (a sibling of the Home item) which content editors would need to add and edit content that would be used by multiple page items under the Home item.
Extend Selecting Sub-Items Publishing Options to Content Editors
The content editor inherits the ability to publish when that role inherits the Sitecore Client Publishing role. Under these conditions, the content editor would not have access to use the republish command option which is ideal. When the republish command is available, a content editor could use it to publish every item to the live site which can take quite a while and use a fair amount of resources in the process. The trade-off however, is that the sub-item and related items publishing options would not be available when a content editor publishes. On a site level publish that may be fine but it can prove problematic for content editors attempting to publish their item level specific changes where they would want to also publish that item’s descendants or its related items. Publishing at an item level is often desirable because content editors want to publish their changes but not impact the work of other content editors who may not be ready to publish their changes. With the options hidden, an item level publish may only publish that specific item and the content editor would have no means to change the option settings.
To expose the publish sub-items and related items option, the security content administrator would open the Security Editor while exposing the Core database of the Sitecore site. The item of interest would be the /sitecore/system/Settings/Security/Policies/Publish/Can Perform Republish in the Core database. If you enable reading on this policy option (by choosing the checkmark on the Read option – image shown below), the content editors will be able to access the publish sub-items and related items option during an item level publish. It will also expose the republish option which when the option is chosen during a site level publish will publish EVERYTHING to the web database. It is a risk, but when I turned on this option, I made very clear to my content editors to never use the republish option EVER to publish items live. In the end the risk was worth the reward to the content editors.
There is another option if exposing the republish command is far from ideal. A custom command can be created in code which would use the sub-item option (or related items option) exposed by the Sitecore namespaces in .NET. Information about how to write this code can be searched, especially on Sitecore’s knowledge bases.
The image below shows the Can Perform Republish item accessible through the Security Editor which allows when set to Read for the content authors to choose to publish sub items and related items when performing a publishing event.
Suggestion for testing Content Editor Access
Create a test account which inherits the role. You can use this account to test security access when changes are made so as to not interfere with the activities of those whose accounts you are updating.
Road map to Set-Up Content Editor Security in Sitecore 8
by Carlos Rodriguez on June 10th, 2016 | ~ minute read
