Permissions
The dotCMS permission system controls user access to all content and back-end functionality through roles and individual user permissions. Every object in dotCMS — from sites down to individual content items — has its own permissions that determine who can view, edit, publish, and manage it.
How Permissions Work#
Roles and Users#
Permissions can be assigned to individual users or to roles, which are then assigned to users. Using roles is strongly recommended, as they allow consistent, maintainable access management across users with similar responsibilities. A user assigned multiple roles receives the most permissive combination of rights across all assigned roles, plus any rights assigned to that user individually.
For more information, see Role Permissions and User Permissions.
Assignable Rights#
Each role or user may be granted the following rights on any object:
| Right | Description |
|---|---|
| View | View the object on both the front-end and back-end, and view the object's properties. |
| Add Children | Create new objects within the location (a Site, folder, or content type). |
| Edit | Modify existing objects. |
| Publish | Publish and unpublish objects so they appear on the live (front-end) site. |
| Edit Permissions | Change the Permissions settings for an object. For content types specifically, this right (combined with Add Children on the parent) is also required to create new content types. |
| Vanity URLs (All Sites only) | Add and edit Vanity URLs across all Sites on the dotCMS instance. |
Permission Inheritance#
Rather than permissioning every object individually, dotCMS supports hierarchical permission inheritance. Sites inherit from the System Host, folders inherit from their parent folder or Site, and content inherits from its parent folder or content type. Inheritance can be broken on any object to set its permissions directly; all child objects then inherit from that object instead of from the higher-level parent.
For more information, see Permission Inheritance.
Permissionable Object Types#
Rights can be assigned for the following types of objects at each level of the hierarchy:
| Object Type | All Sites | Sites | Folders | Objects Rights Are Applied To |
|---|---|---|---|---|
| Sites | Yes | Sites | ||
| Folders | Yes | Yes | Yes | Folders |
| Containers | Yes | Yes | Standard Containers (File-based Containers are governed by Content/Files rights) | |
| Templates | Yes | Yes | Advanced Templates | |
| Template-Layouts | Yes | Yes | Standard (Template Designer) Templates — layouts and content editable in the Page Editor | |
| Pages | Yes | Yes | Yes | Pages |
| Links | Yes | Yes | Yes | Menu Links |
| Content Types | Yes | Yes | Yes | Content Types |
| Content/Files | Yes | Yes | Yes | Content items and Files |
| Category | Yes | Categories | ||
| Rules | Yes | Yes | Yes | Rules |
Permission Inheritance and Locations#
Objects inherit permissions through their containing location:
- System Host — the root of the permission hierarchy; all Sites inherit from here by default.
- Site — Folders, pages, containers, templates, and some content inherit from their containing Site.
- Folder — Pages, files, subfolders, and content of content types that have a Site or Folder field inherit from their containing folder.
- Content Type — Content of a content type that does not have a Site or Folder field inherits permissions from the content type itself.
Access to Back-End Tools#
Role permissions also control which tools a user sees when logging into the dotCMS back-end. Users with different roles see a customized interface that shows only the tools and objects they are authorized to work with.
Access to the REST API#
Permissions also govern REST API access, including which users can view and modify content via the API and the use of API tokens for external application access. For more information, see the REST API Authentication documentation.