Permission Inheritance - Documentation topics on: permission inheritance,.

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

Permission Inheritance

DotCMS objects often adopt their Role-based permissions via hierarchical permission inheritance. Access to dotCMS objects can be controlled through the use of Roles and “inheritable permissions” from “parent objects”, namely the System Host, Sites, Folders and Content Types (see diagram below). An object will only receive “inherited” permissions from its nearest “parent object” that has individual permissions set on it. Meaning, that if a Site has a particular set of permissions, and a Folder on that site has it own permissions, then File Assets, Pages, etc., that reside in that Folder will inherit permissions from the Folder instead of the Site.

Inheritance is optional. Each object can be still permissioned individually if you wish. But, if permission inheritance is set up correctly, it is possible to make child content/objects either editable or hidden to content contributors based on the Role permissions given to the parent objects. Webmasters can set up parent objects so that they pass on their permissions to child objects so that the webmaster does not need to worry about permissioning each child object individually.

Permission Inheritance

To learn more about applying permissions on a specific type of dotCMS object, please see the Object Permissions documentation.

Performance and Backward Compatibility

When you change Permissions on a high-level object (such as a Site or top-level folder), dotCMS must also update Permissions for all objects which inherit Permissions from the object whose Permissions are updated. By default, the current version of dotCMS is configured to perform Permissions updates “lazily”, which means that Permissions changes to lower-level objects which inherit Permissions are not performed until the object itself is accessed. This helps ensure that a single Permissions change to a top-level object does not have a significant impact on performance.

However in earlier versions of dotCMS, whenever you changed Permissions for any object, dotCMS performed all Permissions updates to child objects “eagerly” - meaning that all changes were performed immediately after the initial Permissions change, which could negatively impact performance. For compatibility with older versions, you may configure dotCMS to restore the old (“eager”) behavior by changing the PERMISSIONS_REFERENCES_INSERT_LAZILY property in the dotmarketing-config.properties file to true:

PERMISSIONS_REFERENCES_INSERT_LAZILY=true

Important:

  • This change can have a significant negative impact on performance.
    • Therefore it is recommended that you do not make this change unless it is recommended by dotCMS Support, or you encounter problems when changing Permissions on parent objects.
  • It is strongly recommended that all changes to the dotmarketing-config.properties file be performed through a properties extension file.