Category Permissions

Only administrators may add top-level categories. However you may assign rights to non-CMS Admin users and Roles to add sub-categories and edit/delete all categories (either individually, or for all categories on your dotCMS instance). For example, you may grant users or specific roles the ability to add/edit/delete sub-categories that are associated to content that is contributed by their Roles.

Top-Level Category Permissions#


Permissions over category taxonomies can be distributed from "All Sites", not an individual site, since categories can be used on any content type, on any site. Non-"CMS Admin" users/roles can be given the rights to edit/delete categories at any level, but only "CMS Admin" System Role webmasters can create top level categories.

Creating Top-Level Categories#

To create a new top-level category, a user or Role must be granted both of the following on the System Host:

  • Add Children rights on the System Host.
  • Publish rights for the Category permission under All Sites.

In practice, these permissions are typically held only by users assigned the CMS Administrator Role, as top-level categories define global taxonomies available across all sites and content types.

Editing Top-Level Categories#

To edit top-level categories, a user or role must be granted one of the following rights:

  • Edit rights for the Category permission under All Sites (shown below).
  • Edit rights for the individual top-level category to be edited.

Note: The Category permission is only available under the All Sites permissions in the Roles & Tabs screen. You cannot set category permissions for individual Sites.

Deleting Top-Level Categories#

To delete top-level or secondary level categories, a user or role must be granted:

  • Edit rights on the category to be deleted.

Note: The Category permission is only available under the All Sites permissions in the Roles & Tabs screen. You cannot set category permissions for individual Sites.

Sub-Categories#


Sub-categories inherit permissions from the nearest individually permissioned parent category or, in the absence of individual permissions, from the System Host by default.

Creating Sub-Categories#

To create sub-categories of any top-level category, a user or Role must be granted:

  • Edit rights on the parent category.

Editing Sub-Categories#

To edit existing parent categories or sub-categories, a user or Role must be granted one of the following:

  • View and Edit rights for the Category permissions for All Sites... - OR -
  • Edit rights to the individual permissions of a specific top-level or sub-category.

Permission Inheritance#


All categories are located on the System Host, and by default all permissions for categories are inherited from the System Host. Thus, if you grant a user or Role Edit rights to Category permissions for All Sites, that user or Role will be able to add and edit both top-level categories and sub-categories under any top-level category by default.

Below is an image of a category that is inheriting all its permissions from the System Host. This means that the category is inheriting Permissions directly from the Role permissions themselves set at the System Host or Site level.

Breaking Inheritance#

Once you change the permissions for any top-level category (such as to allow specific roles to edit sub-categories), the inheritance for that category is explicitly (and intentionally) broken. This means that you must individually add each user or Role to the permissions for every top-level category which has been permissioned individually. Sub-categories under a parent category with individual permissions will inherit permissions from the nearest parent with individual permissions.

For more information on setting Permissions on dotCMS objects from the System Host, please see the Role Permissions documentation.