Object Permissions - Documentation topics on: object permissions,permission inheritance,.

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

Object Permissions

To view or change the permissions for any object, open the object properties and select the **Permissions** tab. [Permissions Tab on Objects](/docs/static-images/54980b25-f11f-4ed5-a326-5fee3443241a.png/filter/Resize/resize_w/500) Permissions in dotCMS are assigned via a "matrix" that allows you to assign specific rights to specific objects and/or types of objects. When assigning Permissions, the level of rights granted to a user or role are displayed in columns, and the objects the rights are granted to are in rows. Checking a box grants the user or Role only the rights in the matching column for only the objects in the matching row. The following lists all the possible rights that may be granted to different objects in dotCMS. Note, however, that not all rights are available for all types of objects; checkboxes will be displayed next to a row only when the rights in that column can be applied to that type of object. | Rights Column | Permissions Granted | |:---------------------|:--------------------| | **View** | View the Site or folder in the [Site Browser](site-browser), or when selecting from a [Site or Folder field]() on content. | | **Add Children** | Add objects within a Host (at the top level) or folder. | | **Edit** | Modify an object (but not publish "live" changes to the Site). | | **Publish** | Publish objects so that they appear on the live (front-end) Site. | | **Edit Permissions** | Change the Permissions settings for the object(s) (both for their own user account and for other users and Roles). | | **Vanity URLs**
_(only on **All Sites**)_ | Add and edit [Vanity URLs](vanity-urls) (for all Sites on your dotCMS instance). | The following table lists all the object types that you can grant a user or Role rights to, and where these rights apply (which levels of the Site and folder hierarchy allow you to assign rights to these types of objects). | Object Type | Applies To | Objects Rights are Applied To | |:---------------------|:---------------------------------:|:------------------------------| | **Sites** | All Sites
_(only)_ | [Sites](multi-site-management) | | **Folders** | All Sites,
Sites,
Folders | [Folders](adding-a-folder) (both top-level folders (directly under a Site) and sub-folders) | | **Containers** | All Sites,
Sites | [Containers](containers) | | **Templates** | All Sites,
Sites | [Advanced Templates](advanced-templates) | | **Template-Layouts** | All Sites,
Sites | [Standard (Template Designer) Templates](designing-a-template-with-a-theme) | | **Pages** | All Sites,
Sites,
Folders | [Pages](pages) | | **Links** | All Sites,
Sites,
Folders | [Menu Links](menu-links) | | **Content Types** | All Sites,
Sites,
Folders | [Content Types](content-types) | | **Content/Files** | All Sites,
Sites,
Folders | [Content items](content) | | **Category** | All Sites
_(only)_ | [Categories](categories) | | **Rules** | All Sites,
Sites,
Folders | [Rules](rules) | By default, all objects in dotCMS inherit Permissions from their parent object. This highest level object in the system is the [System Host]() (sometimes referred to as "All Hosts"). Sites inherit Permissions from the System Host, Top-level folders inherit Permissions from the Site, and sub-folders inherit Permissions from their parent folder. If an object is inheriting permissions from another object, the **Permissions** tab will show which object the Permissions are being inherited from. **Note:** If an object is inheriting permissions from its parent object, and the parent object is inheriting permissions from it's parent object, the inheritance cascades. The **Permissions** tab shows which object the Permissions are ultimately inherited from (all the way up to the System Host). For more information on Permission inheritance, please see the [Permission Inheritance](permission-inheritance) documentation. You may change the permissions for any object, assigning permissions directly to the object. When you do this, you "break" the inheritance, so it no longer inherits permissions from its parent object. When you do this, all lower level objects (child objects, grandchild objects, etc.) of the object will now inherit permissions from the object to which you assigned individual permissions. The **Cascade Changes** option applies the Permissions changes you've made to both the object whose permissions were changed and all objects below that object. This includes child objects (Pages, files, folders, and content within a folder), grandchild objects (all objects within subfolders), etc. ----- Do **not** select the **Cascade Changes** option unless you are sure you know what you're doing, and you're sure you need it in order for your Permissions to work as expected. This option will remove any individually set permissions on **_all_** objects below the selected object (including children, grand children, etc.), and should only be used when necessary. If you are unsure whether or not you need to cascade changes, update the Permissions first **_without_** setting the **Cascade Changes** option and check to see if your users have the Permissions they need. If they still can't access objects as needed, you can always comme back and apply the **Cascade Changes** option later. -----