Permissions

Permissions are authorizations – rights – given to users, either because they are members of a specific user group, or because they have a system role such as Administrator. Each permission level, such as the Read permission, corresponds to a specific level of access to a certain part of the system.

The following permission levels can be set:

As you can see, the permission levels form a hierarchy where each new permission level includes or supersedes the previous levels. This means, that a user with Delete permission also has the rights given to the Read, Edit and Create permissions levels. The exception is the None-permission which is hierarchically the highest level of permission but does not include any of the previous permissions – you should think of None as an explicit ban on viewing and interacting with a particular type of content.

If a user is a member of multiple groups with different explicit permissions levels set for the same area the highest permission level is used; Not set < Read < Edit < Create < Delete < All < None.

System roles exist to supply default permissions to the most basic roles on a solution – they are as follows:

As you can see, the system is designed so that Authenticated users (backend) have no explicit permission set for the backend, which means that don’t have access to any features unless specifically granted access. This is by design, as it is much easier to maintain this type of modal than a model where you must explicitly remove access to various sets of users as they are created.

You can always override the default permission for a system role by setting explicit permissions for the role on some content. For example, you may want to deny regular website visitors – the system role Anonymous users (frontend) –  access to a Members’ Area. To do so you can simply add an explicit permission to the root page of the members’ area where the permission for the system roles is set to None.

Permissions are set by right-clicking an element in the backend to open a context menu, then selecting Permissions – this opens the Permissions dialog (Figure 3.1).

As you can see, you can do two things using this dialog:

• See the list of explicit permissions set on this node – here the user group Editors is given Read-permission
• See a list of inherited permissions – here the default system role permissions

To set a new explicit permission click Add group, then select a User group or System role – and use the radio buttons to set the permission level.

Under normal circumstances, permissions are inherited from an element to all elements under it unless a more explicit permission is set. For example, a permission level set on a page is inherited by all subpages, all their subpages, and all paragraphs under these pages unless a more specific permission is set:

• Page 1 (Delete)
  • Subpage 1 (inherits Delete)
  • Subpage 2 (None)
    • Subpage 1 (inherits None)
      • Subpage 1 (inherits None)
      • Subpage 2 (Read)
    • Subpage 2 (Read)
      • Subpage 1 (inherits Read)
  • Subpage 3 (inherits Delete)

In scenarios where the same element can be located under two different nodes – e.g. products which are added to several product groups – the context determines which permission level is regarded as primary. For instance, PROD123 is a member of two separate product groups, one of which is set to explicit None:

• Shop 1 (Delete)
  • Group 1 (inherits Delete)
    • PROD123 (inherits Delete)
  • Group 2 (None)
    • PROD123 (inherits None)

In this case, you can navigate to and access PROD123 via Shop 1 > Group 1 despite the None set on Group 2. If you tried to access the product via Shop 1 > Group 2 you could not – and in fact you would not be able to access Group 2 at all, as it is set to None for you. In cases where the context is unknown – e.g. in queries and searches – permissions are merged in the normal manner and None will supersede the Delete permission, which means PROD123 will not be shown in search results for you.

Permissions set on area buttons – like Content, PIM, and Ecommerce – is inherited by all nodes in the area trees, and then to the content placed under each node in the tree. For example, a permission set on the Users area button is inherited by all user groups, and by all users located in those groups. There are two exceptions:

• Settings: Permissions are inherited from the area button to all tree nodes – but for technical reasons not to the content under each tree node. In other words, the minimum permission you can grant to the Settings area is Edit.
• Apps: Permissions on the Apps area are inherited by all apps under it – which is normal – but please keep in mind that e.g. the Product Catalog is used show products in both backend and frontend, so don’t set Apps to None unless you want to deny users access to the product catalog in frontend.

In general, these two exceptions are not a problem unless you’ve given your backend users too much access by default – and then try to fix this by denying them using the None permission level. Remember, the Not set permission level already means the user does not see content unless granted access.

The Permissions Matrix is a feature which makes it much easier to quickly set explicit permissions for a user group. It is also the only way to set permissions on buttons in the PIM ribbon bar – see this article for details.

It can be accessed from the user group settings by clicking the Permissions button (Figure 5.1). 

This opens the Permissions matrix dialog (Figure 5.2) which contains a list of select parts of the system where permissions are often set.

Figure 5.2 The Permissions Matrix

This list is not exhaustive, but it does make many routine permissions setups a lot more manageable – currently the following areas are available from the matrix:

• Areas
• Websites
• Settings tree nodes
• Ecommerce tree nodes
• PIM tree nodes
• Shops & PIM Warehouses
• Ecommerce languages
• Ribbon bar tools for common products 
• Ribbon bar tools for PIM products
• Ribbon bar tools for Ecommerce products

Please note that since this sets explicit permissions for features, it overrides any permission inherited from a higher level.

Before inheritance was properly implemented, we created a way for you to set a default permission level at the user group level (Figure 6.1).

We no longer recommend using this feature, as the system is designed around rights being explicitly given to users on a need-to basis - and a default permission messes this up, and makes it difficult to bar users from system-critical areas later on.

Figure 6.1 User group permissions

Once a default permission is set for a group, the group permission will be listed as an inherited permission alongside the system role permissions when you set permissions (Figure 6.2).

Figure 6.2 Inherited default permissions

Please note, that the default permission is a fallback value - if you want to quickly configure permissions for the users in a particular group you should use the permissions matrix instead.