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.

System Roles & Default Permissions

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

System 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 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.

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 system 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 system roles
4. Configure the Permission, here you select the permission level
5. Click Save