Content Permissions - Mura Docs v7.0
Mura Digital Experience Platform
Mura Docs v7.0
Return to getmura.com

Content Permissions

Before you begin granting or restricting editing privileges for content, ensure you have completed the first four steps outlined on the Managing Permissions page. You may also want to review the Author vs. Editor Roles section, before continuing.

Permissions cascade from the top-most content item, down through its children, grandchildren, and beyond. By default, all groups granted access to edit the site begin with "Deny" privileges, except for the "Admin" group. The Admin group automatically has full editing privileges throughout Mura.

How to Apply Permissions to Content

  1. From the Content screen, click the three-dot menu of the content item you wish to manage permissions for, and select Permissions.
  2. Or, if editing a content item, click the Actions button, and select Permissions.
  3. From the Permissions screen, select your desired options for each group.
    • Editor
      • Groups granted "Editor" permissions are able to "write" content, as well as "publish" content. This means they can create new content items, update existing content items, delete content items, and even publish content items (or, make them "live"), but only within the section(s) of the site where they have been granted these privileges. The "Admin" group automatically has Editor privileges throughout Mura.
    • Author
      • Groups granted "Author" permissions can only "write" content. This means they can create new content items, and update existing content items. However, they are unable to publish or delete content items.
    • Inherit
      • If selected, permissions applied to the content item's parent will be used. If the parent also has "Inherit" selected, then Mura will traverse up the tree until it finds an explicit setting. If it reaches the "Home" content item, and "Inherit" is selected, the permissions fall back to "Deny."
    • Read Only
      • If selected, users of the group will not be able to edit the content item, or any of its children, unless explicitly overridden with a different setting down the tree. This is very similar to the "Deny" setting, except clicking the three-dot menu of a content item will reveal "Copy" and "Copy All" options. That said, if they choose to Copy a content item with "Read Only" privileges, if the user chooses to "Paste" the content item in an area they have Author or Editor rights to, the content will retain its "Read Only" privileges.
    • Deny
      • This is the default setting for all groups, except the "Admin" group. If selected, users of the specified group will only be able to see the Title, and tree structure of the content. They will not be able to edit the content item, or any of its children, unless explicitly overridden with a different setting down the tree.
  4. Click Update, to save your changes.
  5. Users will obtain the new roles/privileges on their next successful login. So, if a user is logged in when the permissions were updated, they will have to log out, and then log back in, to see the changes.

Note: A commonly asked question is whether or not there is a way to "hide" content, or sections of a site, from certain groups in the back-end administration area of Mura. While there's always a way to do something programmatically, the short answer is no. The primary reason is twofold: just because a group may not be able to edit a top-level section, the group may actually be granted editing privileges to its children or grandchildren, and secondly Mura offers a way to allow for front-end editing only by assigning a user to a Member Group with editing privileges, instead of a System group.