User Permissions

dotCMS objects can be permissioned directly to a user as well as receiving role based object permissions. Large groups of similarly permissioned users can all be easily assigned to the same role, however if a few users in that group need additional access to a few objects, permissions can be quickly extended to those unique users without affecting role distribution.

Only Administrators Can Edit Users

Important: Only User accounts with the CMS Administrator Role can add and modify user accounts. If a User does not have the CMS Administrator Role assigned, they will not be able to make changes to User accounts, even if they have access to the Users Tool in the back-end.

Managing User Roles

You may assign permissions for specific objects to User accounts either directly (in the Users Tool), or via Roles. It is recommended that you assign permissions using Roles whenever possible, since Roles are an efficient way of standardizing permissions to ensure that all users which need certain types of access to a particular resource have the same permissions, without having to update and compare different users.

Assigning Roles

To assign Roles to a User,

1. Select the User.
2. Select the Roles tab.
3. If necessary, expand the top-level Roles to display the Role to be assigned.
4. Check the checkbox next to the Role to assign.
5. Click the right-arrow button (») to assign the selected Role(s).
   • The selected Roles(s) will display in the right-side list of assigned Roles.
6. Click the Save button.

Users can also be assigned Roles while editing the Role. For more information, please see the Role Permissions documentation.

Removing Roles

You can also remove Roles from users via either the Users Tool or the Roles Tool. To remove a Role(s) from a User:

1. Select the User.
2. Select the Roles tab.
3. Select the Role(s) to be removed in the right-side list of assigned Roles.
4. Click the left-arrow button («) to remove the selected Role(s).
5. Click the Save button.

Individual User Permissions

Although it is recommended that you assign permissions to objects through Roles whenever possible, there may be cases where you wish to give an individual user access to specific objects outside of Roles. This can be done either by creating a special Role which is assigned only to the specific User, or by explicitly giving the User permissions to the object in the Permissions tab of the User screen.

To view the permissions assigned to a specific User, select the Permissions tab in the User screen detail area.

When configuring permissions headlessly, such as through an individualPermissions property, permissions should be referenced by system name:

• READ
• USE
• EDIT
• WRITE
• PUBLISH
• EDIT_PERMISSIONS
• CAN_ADD_CHILDREN

Example User Permissions

In the following example, User “John Cook” has already been assigned the “Content Publisher” Role which gives this user permission to add, edit, and publish content. In addition, this user has been given “View” and “Edit” rights to all Templates and Containers on the the System Host - which will allow him to view and edit all Templates and Containers that inherit permissions from the System Host.

Assigned User Permissions from Object Configuration

You may also change individual User permissions when editing specific objects. The Permissions tab in each object allows you to select Roles or Users.

Note: If the object being edited is inheriting permissions from another object, you will not be able to change the permissions for the object. To disable permission inheritance on an object, select the Permissions tab and then click the “Permission Individually” button.

Front-end and Back-end Users

Every User in dotCMS can be configured as a Front-end user and/or Back-end user. Front-end users may submit content via forms on the front-end of your site. Back-end users may login to the dotCMS back-end.

You may configure these properties for each user in the Access section of the User configuration screen:

Access to Content and APIs

The following table shows what content a user has access to, based on whether the user account has been configured for Front-end User and/or Back-end User access, and whether an API Access Token assigned to the account is used when performing a REST API call:

REST_API_REJECT_WITH_NO_USER=true
CONTENT_APIS_ALLOW_ANONYMOUS=write