Permissions

Permissions are authorizations – rights – given to users, either because they are members of a specific user group, or because they have a user type such as Administrator, Admin or Editor. 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:

Permission level	Description	Included permission
Not set	No rights	-
Read	Can access and view content/settings	-
Edit	Can edit existing content/settings	Read
Create	Can create new content/settings	Read, Edit
Delete	Can delete content/settings	Read, Edit, Create
All	Can set permissions	Read, Edit, Create, Delete
None	No rights	Overrides all other permissions

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.

Permission levels can be set to specific User Groups by being in edit-mode on the user group and change the settings on Default permission. The members of the user group will now inherit the set permission level.

User Roles & Default Permissions

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

User Role	Default permission	Description
Anonymous users (frontend)	Read	You usually want anonymous visitors to have access to the frontend
Authenticated users (frontend)	Read	You also typically want logged-in users to have access to the frontend
Authenticated users (backend)	Not set	Backend-users are not explicitly given any rights. This means that by default they see a blank page. Remember, Not set is the lowest permission level and any inherited permission overrides it
Administrators	All	Administrators are given All permissions by default, which means they can set permissions

As you can see, the system is designed so that Authenticated users (backend) have no explicit permission set for the backend, which means that they 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 model 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 user role by setting explicit permissions for the role on some content. For example, you may want to deny regular website visitors – the user 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 user roles is set to None.

Setting permissions

Permissions are set in the backend by opening the context menu of an item in the area tree, and then selecting Permissions. This opens the Permissions workspace of that specific item. Here you can see the inherited permissions that the user roles have by default, and User Groups with default permission levels.

To create explicit permissions for the specific item, do the following:

1. Click New permission
2. Select the Owner type, a user group or a user role
3. Select the Owner
   • If user group is selected, you choose a user group or a query
   • If user role is selected, you choose between the different user roles
4. Configure the Permission, here you select the permission level
5. Click Save

Examples

To provide you with hands-on examples of how to setup role-based permissions, we will set up permissions of the following roles:

• Content managers
• PIM managers
• Commerce managers

These are fairly standard user roles but please keep in mind that the first step of any permissions setup is to describe, in detail, what you want each role to be able to see and do.

As mentioned above, permissions are granted to users based on either user type or user group membership.

Since we don’t want these users to be administrators (who can see and do everything), you should first create a user group for each role:

1. Go to the Users-area
2. Under Groups create three new user groups:
   • Content managers
   • PIM managers
   • Commerce managers
3. within each group, create a user and check the 'Allow backend login for this user' and 'Active'

You can now log in with these users – but they won’t be able to see anything, as they have not been granted any permissions:

Let’s change that!

Content managers

Content managers are responsible for handling everything related to content management:

• Planning, creating and editing content
• Handling assets – specifically media files like images and videos

First give them access to the overall Content area:

1. Log in as an administrator user
2. Open the content tree, then click the context-menu for the tree and select Permissions
3. Click + New permission:
   • Owner type: user group
   • Owner: Content manager
   • Permission: Delete
4. Save

Content manager should be able to access all media files within Assets. However, we don’t want content managers to be able to change design files or edit system files, meaning they should only have Read-access to the Assets area: Open the Assets-area, then click the context-menu for the tree and select Permissions

1. Open the Assets-area, then click the context-menu for the tree and select Permissions
2. Click New permission:
   • Owner type: user group
   • Owner: Content manager
   • Permission: Read
3. Save

We do want them to be able to create, edit and delete media files – as this is important for content management:

1. Open the context menu for the Media section of the Assets-tree and select Permissions
2. Click + New permission::
   • Owner type: user group
   • Owner: Content manager
   • Permission: Delete
3. Save

Now login with the content manager user – you should now have access to the relevant areas:

PIM Managers

PIM Managers need to be able to access and work with the Products area as this is where product information is maintained. They also need access to the Assets area so they can work with product images and other assets.

First let’s grant them access to the assets. As with content managers, we don’t want them to be able to change design files or edit system files, so we will only give them Read access to the overall Assets area:

1. Open the Assets-area, then click the context-menu for the tree and select Permissions
2. Click + New permission:
   • Owner type: user group
   • Owner: PIM Managers
   • Permission: Read
3. Save

They should be able to create, edit and delete media files – as these are essential for enriching products:

1. Open the context menu for the Media section of the Assets-tree and select Permissions
2. Click + New permission:
   • Owner type: user group
   • Owner: PIM Managers
   • Permission: Delete
3. Save

Besides access to media assets, PIM managers should of course have access to the Products area:

1. Open the Products-area, click the context-menu for the tree and select Permissions
2. Click + New permission:
   • Owner type: user group
   • Owner: PIM Managers
   • Permission: Delete
3. Save

It is also possible to give permissions at a lower level, such as shops, warehouses or even groups within a shop. An example could be that you have two shops, shop A and shop B. You want certain people to have access to shop A and not shop B and vice versa. To achieve this, you would configure their permissions accordingly:

1. Set the permission to read for the Products tree
2. Set the permission to delete for their designated shop

When a user within the PIM managers user group is logged in, the page will now look like this:

Commerce managers

Commerce managers are responsible for handling everything related to commerce, and this includes:

• Order management
• Assortments
• Promotions
• User accounts

Meaning that the commerce manager needs access to the users, email and commerce areas.

Within the Users area, the commerce manager usually needs reading access to the customers information but more than that is rarely needed. This could be to gain insights into consumer behavior, trends, and preferences. Commerce managers can use this data to analyze sales performance and identify areas for improvement.

Here is how to achieve this:

1. Open the Users-area, click the context-menu for the tree and select Permissions
2. Click + New permission:
   • Owner type: user group
   • Owner: Commerce Managers
   • Permission: Read
3. Save

The Commerce manager should also have permission to the Emails area to be able to work with email marketing.

1. Open the Email-area, click the context-menu for the tree and select Permissions
2. Click + New permission:
   • Owner type: user group
   • Owner: Commerce Managers
   • Permission: Delete
3. Save

Like with the others, it is possible to grant permission on a lower level if needed.

Lastly, the commerce manager needs to be granted permission to the commerce area, as this is where commerce tasks like order management and promotions are located:

1. Open the Commerce-area, click the context-menu for the tree and select Permissions
2. Click + New permission:
   • Owner type: user group
   • Owner: Commerce Managers
   • Permission: Delete
3. Save

When a user within the commerce managers user group is logged in, the page will now look like this: