In a recent project, I was asked to implement a feature I had not worked with before—field access rights. As with many things in Sitecore, access rights are typically easy to implement. If you’ve worked with any requirements around security in Sitecore, the image below of Sitecore’s security rights interface will be familiar.
The image in Figure 1 shows the standard view of access rights before configuration. Notice the left-to-right headings for Read, Write, Rename, Create, Delete, Administer and Inheritance. For the most part, these are self-explanatory and generic CRUD operations. However, “Administer” and “Inheritance” may require more explanation, which is provided courtesy of the definitions in Sitecore documentation:
- Administer — controls whether an account can configure access rights on an item. The administer access right requires the read and write access writes.
- Inheritance — controls whether security rights can be passed from the parent items to the child items. The security model supports the possibility to choose inheritance on a per account basis (applies to all access rights). The inheritance settings you choose apply to the selected account only.
You may have noticed that this doesn’t have much to do with field level. Fortunately, the visible columns are configurable. In Figure 2 below, note that clicking the Columns button on the ribbon produces the following screen:
Selecting the Field Read and Field Write check boxes produces new columns as seen below in Figure 3 below:
Note that the checks and X mark options don’t appear in the Field Read and Field Write columns because the visible items are not fields, and thus cannot have field-level access rights applied to them. But, if we navigate to Templates in the directory tree, you can see that the check and X for enabling/disabling read and write field access appear, as in Figure 4 below:
Read and write access do pretty much what you’d think - read allows a user to see the field and write allows them to edit it. This can be very useful if you have any users that will need to access common fields across many item templates but not the unique fields for each one. An example of this is a Media Editor who should only have access to images and videos or an SEO user editing common meta information fields across the site but not the content itself.
The only downside I have found with field level access rights is that there is no concept of inherited access rights. For example, if you wanted to give a user access to the entire media library, you can simply check the read and write permissions in the view below and they will be granted to the item and its descendants. While this feature would be nice when you want to restrict access to most of the fields on a field-heavy template, currently each field must be configured individually, as illustrated in Figure 5:
If you want more information about Sitecore’s default security features and other configuration options, please see Sitecore’s own documentation.