Category Permissions - Documentation topics on: category permissions,.

This documentation is a static copy for this version. For current documentation, see: http://dotcms.com/docs/latest

Category Permissions

Only adminstrators 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

Only users assigned the CMS Administrator Role may ADD new top-level Categories.

This is an intentional limitation ensuring that only administrators can create entirely new taxonomies (Category hierarchies) that can be utilized from all sites on any content type.

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 can not set Category permissions for individual hosts.

Deleting Top-Level Categories

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

  • Edit Permissions rights for the Category permission under All Sites.

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

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 Permissions rights for the Category permissions under All Sites.

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

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 permissons themselves set at the System Host or host* 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 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.