Eval Criteria # 16

Can access to types and attributes be limited by user permissions?

Not every type and attribute is created equal. They can differ greatly in terms of necessity, complication, and consequences.

Some content types – Text Page or Article – might be ubiquitous and straightforward. Others – Home Page or Image Carousel – might be less so.

The same is true of attributes. The model behind a type isn’t a single unit, remember – it’s a collection of attributes, and sometimes we can vary access to them individually.

Every editor probably needs access to the Title and Body, but what about the URL Segment or the Suppress Navigation checkbox? Are these things every editor is trained for? Are these things you want every editor to be able to change?

Some systems offer permission-based access to different aspects of the content model. This can be used as a form of coercion – you can promote good editorial practices by preventing editors – by individual or group – from affecting certain types and attributes.

We mentioned above that not every aspect of the content model is created equal, but here’s an additional, awkward truth – not every editor is created equal. Throughout this text, we’ve lumped editors together in one group, but there’s a wide range.

Bookending the “normal” editor are (1) lighter-weight editors who might only do one thing with the content, and (2) “power” editors, who are quasi-administrators who can do everything with content, and even some configuration and pseudo-development when necessary.

Working with some content types might require additional training. There might be image sizing, format, or focal point considerations; the attributes of the particular object might have far-reaching implications; or changing the value of an attribute – especially in tree-based systems with cascading implications – might risk violating an organizational standard.

This speaks to both content model resiliency and editorial usability. Not only do we want to protect our content, but there’s nothing more demoralizing for an editor than inadvertently breaking something they were unaware could break.

Singleton Types

Some content types have intentionally limited use. For example, the Home Page. By definition, there’s one per website, so there’s very few reasons why one would need to be created after site launch. In programming, structures which should only have a single instance are known as singletons.

Additionally, in many tree-based systems, a common pattern holds that global properties are modeled and stored on the home page object. This is due to both (1) the singularity of the home page, and (2) the ability for cascading attributes on the content root (which is often the home page) to affect every object in the tree, since everything else is a descendant.

There might be other types that aren’t pure singletons but are rarely created post-launch. Entire new sections of the website, for example, might require the creation of a new Section object, but this needs to be accompanied by multiple other changes and content restructuring, or else the website might begin to malfunction. As such, access to the Section type should be limited to a few power editors who would likely be involved in or spearhead a large-scale change such the creation of an entirely new section.

Type Permissions

Many systems will offer type-level permissions – permissions for object creation based on type so certain types can be restricted from certain editors.

This is only applicable on object creation, since once an object is created, its permissions will revert to those on the object, rather than the type the object is based on (and many times, those permissions will be inherited from its parent). You can’t put a permission on something that doesn’t exist. So, the only way to control the ability to create an object is to put that permission on the type.

In our home page example, we could simply remove all object creation permissions for the Home Page type once the home page has been created during site development. If no one can create another one, then the sole Home Page object will safely remain a singleton.

Some systems also have the ability to remove the option for anyone to create a specific type, globally (via a setting called “Do Not Show in UI” or something similar). While this has the same basic effect as removing all permissions as described above, sometimes this is available on systems with no other type restriction system. While it doesn’t provide the granularity of type restrictions, it does protect the uniqueness of singleton objects.

Attribute Permissions

In addition to types, sometimes we want to protect content with attribute-level permissions, where edit or view restrictions can be placed on specific attributes. This means the ability to create or edit a type might not give an editor access to the entire object – certain attributes can be read-only, or even removed from the interface entirely.

For example, perhaps only advanced editors should be able to change the URL Segment attribute. For all other editors, the editorial element for this attribute can be removed from the interface. Our editors assigned to a specific group would see the editorial element for that attribute as normal, while other editors might never know it exists.

Clearly, if you remove an attribute, that attribute cannot be required. Our URL Segment field from above would likely be auto-populated if left empty. However, if an attribute requires a value, and that editorial element is hidden from view, this is going to cause a problem.

In systems where attributes can be aggregated into tabs or collapsible panes, it’s sometimes possible to apply permissions to entire groups of attributes at a time. For example, we might aggregate attributes like SEO Keywords and SEO Description into a tab or pane called “SEO Info,” then restrict access to only the marketing team. Attributes added to this group should be automatically restricted in the same way.

Attribute Permissions and Templating

So far, we’ve discussed model permissions around the editorial interface. But some systems extend that to their templating systems as well, which can be tricky.

Some systems have very integrated templating, where templates are modularized to the attribute level. These systems might even apply attribute-level permissions on the rendering side as well, so that certain visitors/users can’t see certain information.

However, this can be difficult to manage, because templating operates on such a wide range of visual interpretation. Only very structured design systems can cope or recover from the arbitrary elimination of rendering information at request time. If any attribute can be restricted, then technically the design system has to be prepared for any aspect of the content object to simply not be available during rendering. This is asking a lot.

When the delivery context executes, it will know the identity of the user (even if that identify is the “Anonymous User”). When you do genuinely have a situation where a specific attribute should be hidden from a specific class of user, it’s usually not just the attribute value that needs to be suppressed. Attribute values are normally formatted with surrounding HTML constructs, and, in most every case, those all need to be suppressed as well.

For instance, you may have Mobile Phone attribute on your Employee Bio type for your intranet. Access to an employee’s personal phone number is on a “need to know” basis, so this should only be displayed for users in the “Security” and “Help Desk” user groups.

However, that attribute value isn’t rendered by itself – there’s likely a label next to it, and some container HTML construct – perhaps an entire table row. All of that needs to be removed too, but in most templates, there’s no way for that arbitrary conglomeration of HTML to “know” that it belongs to the attribute which is no longer visible.

The only time this works well is when the templating and design system is deeply integrated into the content model, and each attribute somehow “carries” its own template, so the entire construct can be suppressed. You see this templating philosophy in some systems, but it’s not common, and further discussion is far beyond the scope of this chapter.

In most cases, attribute removal during rendering would be accomplished in the template logic by a simple if…then construct that would either (1) manually check the group (for the “Help Desk” group discussed above), or (2) have access to some IsDisplayed property of the attribute object itself.