Permissions (Beta)

As of Dynamicweb 9.4, you can switch from the permissions model you all know and love to a more granulated model which allows you to set permissions on (almost) everything using the same unified and flexible permissions model. This is a major upgrade to the existing model, as it allows you to create specialized user groups and only give them access to the parts of the solution which they should have access to. 

The new permissions model is currently implemented for:

  • Menu buttons (Home, Content, Files, Users, Ecommerce, Marketing, PIM, Apps, Settings)
  • All trees nodes (Content, Files, Users, Ecommerce, PIM, Marketing, Settings)
  • Website settings
  • Apps (defaults to Delete for Authenticated users)
  • Settings:
    • Ecommerce languages

To use the new permissions model, you must first enable it. Go to Settings > Control Panel > Users and check the use new permissions model (Beta) checkbox(Figure 1.1). If you do not see the checkbox on a version after 9.4, contact your partner account manager to add the new model to your license.

Figure 1.1 Activating the new permissions model

Once the new permissions model has been enabled, you can right-click elements in the backend and click Permissions to access the permissions control dialog (Figure 1.2).

Figure 1.2 The permissions dialog

From this dialog, you can:

  • Set explicit permissions for a user group or system role
  • View permisssions inherited from a user group or system role

The permissions hierarchy and permissions levels are explained in the next section, and system roles are explained in the section after that.

The different permissions levels you can give a user group form a hierarchy, where each permission level includes or supercedes the previous levels. This means, that if a user has Delete permissions she also has Read, Edit, and Create permissions.

The exception is the None permission, which is hierarchically the highest level but does not include the previous permissions. Think of None as an explicit ban on viewing and interacting with content.

Permission level

Description

Included permissions

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

Permissions apply to both the frontend and the backend – so a user with an explicit None permission for a particular area or website is effectively banned from accessing that area or website in both frontend and backend. This is true, even if a user is an Admin or an Administrator. The hierarchy reigns supreme.

In typical scenarios, you want to have different default permissions for the frontend and the backend of a website:

  • Users should have access to frontend content unless explicitly denied access
  • Users should not have access to the backend content unless explicitly allowed access

Enter system roles.

System roles exist to supply default permissions to users who are not placed in a group for which explicit permissions have been set. This means different permission levels can be assigned to e.g. anonymous frontend users (Read), and backend administrators (All).

By design, the following system roles and default permissions are used:

System Role

Default permission

Explanation

Anonymous users (frontend)

Read

You typically 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 permission by default. This means that by default, they see a blank page.

Administrators

All

Administrators are given All permissions by default, which means they can set permissions.

We do not support editing system roles and their default permissions, although all default permissions can be overridden by setting explicit rights for the system role. Instead, we recommend that you set default permissions at a user group level.

Banning yourself

Please note, that if you set the permission for Authenticated users (backend) to None, you effectively ban all non-Angel accounts from accessing that area. This includes your own account. So don’t do that...

Like system roles, regular user groups can have a default permission level – this is set when creating or editing the user group settings (Figure 4.1):

Figure 4.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 setting permissions ({figurere}).

This can be be very useful when setting up permissions across a solution – both as an overview, or because you want to effectively replace a system role permissions with a higher level default permission on a particular user group.

Figure 4.2 Inherited default permissions

An important concept to understand about permissions is inheritance. By design, all content under an element with permissions set inherits the permissions of that element, unless a more explicit permission is set.

This means that if you set permissions on e.g. a particular page, they are inherited by all subpages under it, all their subpages, and the full collection of paragraphs under those 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)

Where pages can only be located in one place in the tree, things are a little different when it comes to products; a single product may be a member of more than one product/warehouse group. This has some implications for how permissions are inherited.

For example, Product 1 is a member og two groups – one of which is explicitly set to None permission:

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

In these cases, the context determines which permission level is primary – so you can navigate to and access Product 1 through Shop 1 > Group 1, despite the None permission inherited from Group 2. In cases where the context is unknown – most notably in queries & searches – permissions are merged in the regular manner and None will supercede the Delete permission, which means Product 1 will not be available in search results.

If a user is a member of several groups with different explict permission levels for the same area, the highest permission level is used; an All permission overrides a Read permission, and a None permission overrides an All permission.

In this example, a website administrator is a backend user with permissions for a single website and the other parts of the solution associated with that website:

  • The design folder for the website
  • Select user groups
  • An Ecommerce shop and select tools

To keep thing simple we’ll create three separate user groups for the scenario (Figure 6.1), and a new user in the Website Administrator group to test with. Check the Allow backend login setting for this user.

Figure 6.1 Creating user groups for the example

Users in these groups start out with only the permission levels inherited from system roles:

  • Read when visiting the frontent
  • Not set when logging into the backend

This means that they can see frontend content, but when they log in they see.. nothing (Figure 6.2):

Figure 6.2 No permissions set

Let’s change that by setting some permissions - first, we must set permissions on the relevant areas in the left side menu; Home, Content, Files, Users, and Ecommerce.

Area permissions control one thing only – whether the user can see and click on the button for the area.

Log in with an administrator account and:

  • Right click on the Home area button
  • Open the permissions dialog
  • Click Add group
  • Select the Website Administrator user group
  • Set the permission level to Delete (Figure 7.1)
Figure 7.1 Area button permissions

Repeat the process for all areas which the user should have access to – in this case Home, Content, Files, Users, & Ecommerce.

When a user in the Website Administrator group logs in, she can now see the following (Figure 7.2):

Figure 7.2 Area buttons are now visible

While the Area-buttons are visible, the area trees are empty since no explicit permissions have been set for them. Let’s change that.

A Website Administrator should have access to all website settings for a single website and all associated language layers.

  • Log in with an administrator account
  • Open the website settings for a website
  • Click on Permissions in the ribbon bar
  • Add the Website Administrator group and set permissions to Delete

Log in with the Website administrator user and verify that she has access to website content and website settings for a single website and any language layers added under it.

If you want the website administrator to have access to all content but not the website settings, you can use the Page permissions node in the Content tree context menu (Figure 8.1).

Figure 8.1 Content Permissions

For the file archive, we want to give Website Administrators access to only select folders related to the particular website - the design folder for the website and the Images folder.

To make that happen:

  • Log in with an administrator account
  • Open the Files area
  • Right-click the Templates folder and open the permissions dialog
  • Add the Website Administrator group and set permissions to Read

This allows the users to view the Templates folder and all subfolders – but not add, edit or delete files. We need to provide Read acces to allow the user to navigate to the folders where they have more permissions.

Now, set a higher permission level for the design folder for the website:

  • Fold out the Designs folder
  • Right-click the design folder for the website and open the permissions dialog
  • Add the Website Administrator group and set permissions to Delete

The Read access which was inherited from the Templates folder is now overridden for the design folder and any folders under it. We don’t set the permission level to All as we don’t want the Website Administrators to be able to set permissions on the design folder.

Repeat the process and set permissions to Delete for the /Images folder. Log in with a Website Administrator user and verify that you can view the Images and Templates folder and subfolder, and interact with files in the Images and Templates/Designs/Yourdesign folders (Figure 9.1).

Figure 9.1 File permissions applied

When it comes to users, we want the website administrators to have full rights to the users associated with their particular website – in this scenario Content Editors, Customers and PIM Editors. We also want them to be able to view (but not edit) the list of Website Administrator accounts.

You know the drill by now – to make that happen:

  • Log in with an administrator account
  • Right click the Content Editors user group and open the permissions dialog
  • Add the Website Administrator group and set permissions to Delete
  • Repeat the process for the Customers and PIM Editors groups
  • Repeat the process for the Website Administrators group, but set permissions to Read

Log in with a Website Administrator account and review the results – the user can now see and interact with the Content Editor, Customers and PIM Editor groups (Figure 10.1). She can also view (but not add, edit or delete) accounts in the Website Administrator group.

Figure 10.1 User permissions applied

For Ecommerce, we want the Website Administrator account to have access to content related to only one website – the Dashboard, a single shop, and select tools used on the solution.

As with the Files archive, we need to provide Read access to the entire product catalog to allow the user to navigate to the shop where she has more extensive permissions:

  • Log in with an administrator account
  • Right-click the Product Catalog node and open the permissions dialog
  • Add the Website Administrator group and set permissions to Read
  • Right-click a shop and open the permissions dialog
  • Add the Website Administrator group and set permissions to Delete

With these permissions, a website administrator will be able to view all nodes under the Product Catalog. If you want to hide something – e.g. another shop, or the Assortments tool – you can open the permissions dialog for the element and explicitly set the permission level to None. If not explicitly set, all subnodes inherit the Read permission from the parent node; Product Catalog.

Set up the remaining Ecommerce permissions for the Website Administrator as you envision them – they probably need access to at least Orders for their shop. For tools which are not used on a solution, e.g. Recurring orders or Loyalty points – simply set no explicit permissions and they won’t be shown for the Website Administrator users (Figure 11.1).

Figure 11.1 Ecommerce permissions applied