My SUGCH presentation from April 29 2019 about Field Whitelisting can be found on slides.com.
After Sitecore instances are running for a few years, templates tend to get cluttered with fields that have no meaning for content authors, like optional, legacy, or purely technical fields. In this post, I present a practical approach to hide all fields that are irrelevant to content authors.
The Situation
We all know the nice and clean templates that Sitcore shows in their marketing presentations. If you are lucky, your templates look like this… at least in the beginning of a project.
Unfortunately, chances are that after a few years your templates look more like this:
The Issue
With more and more features, templates tend to get cluttered with lots of fields. Optional fields and flags, legacy & technical fields, dropdowns with a single value… they all draw authors attentions from the important fields and are one of the reasons they do not use the Content Editor. This is what I like to call Field creep, derived from the project management term Scope creep, which refers to “changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins“.
The access rights field read and field write would help but adding these rights is an additional step often missed in the development process.
The Solution
Since most of the fields are irrelevant to most of the authors, it might be easier to hide all fields from them and only show those that are relevant. The easiest way is to generally remove field read access in the standard values of the Template field Template.
You will want to use new roles, so your active users are not compromised by this change. Don’t worry that you are unable to see these access rights in the Security details tab, you will see them in the Assign Security Rights dialog.
In the given example, I prevented field access rights for a simple editor and an advanced editor. If you would now assign any of these roles to an author, all of the fields would be hidden and he would see a message that the template does not have any fields. Since that is not what we want, we now grant access for the “simple” fields to the simple editor. We do that by editing he Security field of the fields in our templates.
The first thing we see is that the security has been correctly taken over from the standard values of the Template field Teplate. Thanks to this, granting access to our field is as simple as clicking the green checkmark for both the roles.
Kudos to Sitecore for following their principles all the way up the template hierarchy, I was worried fields might be treated differently.
Repeat the steps for all relevant fields. The fastest way I found is copying and pasting the content of the security field in Raw values view.
That’s it! You have now whitelisted fields for all users with this role.
For this example, I granted the Simple Editor access to the fields Title, Abstract, and Text. If you assign this role to an editor now, his view greatly simplifies (Legacy Editor vs Simple Editor):
This is a much cleaner view of the item and simplifies editing to agreat extent. You can show additional fields to other roles, hence completely tailoring the content view for your authors.
It is important to note that the field read access right is only for convenience and has no security implications, e.g. in the Experience Editor. If the field is visible there, it can be edited – even if field read access is forbidden. We are lucky here because that is the behavior we want, otherwise the Experience Editor would break.
When you switch user to a legacy editor, you can verify that nothing changed for him, all the fields are still visible. After you are done testing your new roles, enabling field whitelisting for them is as simple as assigning them one of the newly configured roles.
Review
Let’s analyze the solution to see what we have gained and how we achieved it.
Implementation
I would rate the implementation a solid 9/10. We did not write any code, we did not change any configuration and the only thing that changed in the “Sitecore domain” of the content was the standard value of one template (although I agree it is a crucial one). You could literally implement this approach on a production machine in an hour. It is fully backwards compatible and very low risk since users are only affected once you assign them one of the new roles.
What do we gain?
Make no mistake: the simplicity of the solution does not mean there is little impact. By inverting the approach from showing to hiding all fields by default, we changed the way developers and authors perceive fields.
For Authors
- Stability
Authors now have a much more stable editing experience, since new fields are hidden for them – except when they are relevant. - Simplicity
Content authors will always see the minimal number of fields for managing their content. - Focus
Relevance of fields can be easily tied to author roles, so different authors can have different views on the same item. - Robustness
Some fields have the power to mess up the whole site, even when they are located in a tiny subsection. You can easily prevent novice authors from changing these fields.
Developers
- Certainty
If a field is not assigned the correct access rights, testing the feature will fail. Additional fields normally do not lead to a failed test and slowly clutter the templates. - Awareness
Developers now have to give access rights. This forces them to think about the usability of features by non-technical users. In addition, the business might already have to define who should be able to use which feature. - Freedom
Developers can now add pretty much arbitrary fields to their templates, without fearing that editors break something or misinterpret the fields.
Why not just remove the access?
Although most of these features were available in the “classical” way of removing read access, that approach typically does not succeed. Field access is getting revoked reactively – normally when something went wrong – and developers tend to forget about access rights, making the Content Editor increasingly less usable. At some point, authors retreat to the Experience Editor because they don’t want to deal with the mass of fields anymore.
Summary
Whitelisting fields is a simple way to break the vicious circle of increasing item complexity and decreasing number of Content Editor users. Our first experiences at productive client solutions are very promising. Make your authors happy!
Happy not coding!
