Managing User Access via Type-Based Access Rights

​Any user’s access to site data is determined by their access rights. Your access rights determine what data you can see, and what data you can modify. They also determine what data items you can create, and which you can delete, if any. ​

Some of these access rights are established by your site’s developers, but a business user with the right permissions can set certain access rights for other users. And yes, permissions is just another name for access rights! ​

​The following access rights can be granted:

• Read
• Change
• Create
• Remove

​Naturally, some of these are usually combined. It doesn’t make much sense to have Change permissions without also having Read permission. Likewise, being able to create an item usually means you will need to be able to change its values.

​The following permissions may be defined in Backoffice:

• Type Permissions define your access rights to an entire data type, like Product or PriceRow. The actions that can be granted or denied are Read, Change, Create, and Delete. By default, Read and Change permissions to a Type instance extend to its attributes.

• Attribute Permissions allow or restrict Read and Change access to individual attributes of a Type instance, overriding the Type-level permission for that specific attribute.

​More general access rights exist, called Global permissions, which grant access to functionality, such as catalog version synchronization or activating workflows. They must be set by developers and so aren’t covered in this course.

​In a similar vein, more specific access rights also exist, called Item permissions. These allow fine-grained access control to permit or restrict access to individual item instances. There can be significant performance implications to using Item Permissions, and they can only be set by developers. For those reasons, we won’t be discussing them further.

​Permissions can be assigned to a user or a user group. The permissions assigned to a user group are inherited by all users who belong to that user group. This is the preferred way to assign permissions. ​

A user groups can contain other user groups, who inherit its permissions. Each subgroup may override these inherited permissions, expanding or restricting the effective access rights inherited by their users.

​In the example below, special_projects inherits read:granted / change:denied to the Product item from its parent, project_group. If a user belongs to multiple user groups, either directly or hierarchically, they inherit the permissions of all these groups. In the event of a conflict, the permissions closest to the user in the hierarchy take precedence.

​In the example below, Brigit is granted read and change access to the Product type based on her membership in the product_mgmt group, but she is denied change access based on her membership in project_group. However, her membership in product_mgmt is closer in the hierarchy, so it takes precedence, and she is granted change access..

​Let’s enhance the previous example a bit: ​

To keep it simple, special_projects inherits again from its parent, project_group, but this time explicitly alters access to the approval property of Product, prohibiting it from being read or changed. ​

In our example, Brigit is again implicitly granted read and change access to all the properties of Product from product_mgmt, but denied change access to the ‘approval’ property based on her membership in special_projects. Since the conflicting permissions on this property are both equally distant from Brigit in the hierarchy, the most restrictive one is picked, so the access is set to 'deny'. ​

This is illustrated in the diagram below. Everything known from the previous example is grayed out to put your focus on the parts that have changed.

​Let’s see how to grant access rights to a user group. The process is the same for a user, but we’ll focus on the preferred method of granting access rights, which is via user groups. ​

The Backoffice Administrator can grant a user group access rights to any item type by clicking the key icon in the edit user page (see the screenshot below). This brings up a dialog showing existing access rights explicitly granted to this user group – in the screenshot, that’s the Backoffice product manager group. ​

The dialog lists the read, change, create, and remove permissions the Backoffice product manager group has for each item type in the list. If an item type you want to modify permissions for does not appear in the list, you can add it to the list by clicking the + icon.

​In the screenshot, the Backoffice product manager group has read, change, create, and remove permissions for the first four item types listed, with the exception of the first, where members of that group will not have the ability to delete entities of this type. This is denoted by a red X in the remove column of that item type.

​When you select an item type, for example Bundle Rule in the screenshot below, a list of its properties is displayed on the right. Properties cannot be created or deleted, so the only permissions available are read and change.

​By default, all properties have the same permissions as their parent object, so if a user can change the object, they can change all the property values. However, you may change this access by clicking on the checkmarks to change them to a red X. Clicking the item again will revert to a checkmark, indicating the access is granted.

​In the screenshot below, the Backoffice Administrator has denied users belonging to the Backoffice product manager group permission to change the documents property, and removed all access, both read and change, to the comments property. ​

As a result, if the Backoffice product manager group's users edit an item of type Bundle Rule in Backoffice, the value of the documents property will be grayed out, indicating they can’t alter it, and the value of the comments property will not appear at all.

​A core part of any commerce website, the product catalog is structured into versions, allowing catalog content to be edited in Backoffice without affecting the production website. Once the changes are finalized, the data can be synchronized to production. ​

Access to products in these catalog versions is controlled by an entry in the Personalization tab of a user or user group. A user will only be able to view catalog versions that appear in their own Readable catalog versions list, or in the Readable catalog versions list of a user group they belong to. ​Likewise, that user can only alter catalog versions that appear in the Writeable catalog versions list.

​Let’s watch a Backoffice user create a new user and assign appropriate permissions.