Form Permissions - Mura Docs v7.0

Form Permissions

Managing permissions for forms is very similar to managing content permissions, because forms can be grouped together in a hierarchy, just like content. As you've seen in the Forms section, you can nest a form, or a group of forms together under a Folder, or other forms. Not only does this make it easy from an organizational point of view, it really simplifies things from the viewpoint of enabling or restricting editing permissions as well.

As you've already learned, permissions cascade from the top-most 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 Enable/Disable Forms Manager

To enable or disable the Forms Manager, follow the steps below.

  1. From the back-end administration area of Mura, select Site Settings, then click Edit Settings.
  2. Select the Modules tab.
  3. Locate the field labeled Forms Manager, then select "On" to enable it, or "Off" if you wish to disable it.
  4. Click Save Settings.

How to Apply Permissions to Forms

  1. From the Content screen, on the Tree View tab, click the Forms button.
  2. Since all non-Admin groups begin with "Inherit" privileges, they will not be able to see the "Forms" button on the Content > Tree View tab. For example, the following screen is what a "Marketing Group" user would initially see before permissions for forms have been explicitly set. As you'll notice, this user is unable to see a "Forms" button at all.
  3. The first thing you'll want to decide on is whether or not you want the group to be able to edit forms by default. Then, you'll set permissions on the top-level "Forms" item itself, and those permissions will cascade down through the rest of the forms. So, if you explicitly set the group's permissions on the top-level Forms item to "Deny," the group will be able to see the "Forms" button on the Content > Tree View screen, and by default, they won't be able to actually edit anything, unless you explicitly set the group's role to "Editor" or "Author" by following the rest of the steps below. Conversely, if you set the group's permissions on the top-level Forms item to "Editor" or "Author," the group will inherit those rights throughout the Forms area, unless explicitly overridden somewhere down the tree. Follow the steps below for editing the permissions of the top-level Forms item itself.
    • Editor
      • Groups granted "Editor" permissions are able to "write" forms, as well as "publish" forms. This means they can create new forms, update existing forms, delete forms, and even publish forms (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" forms. This means they can create new forms, and update existing forms. However, they are unable to publish or delete forms.
    • Inherit
      • If selected, permissions applied to the form'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 Mura reaches the topmost form, and "Inherit" is selected, the permissions fall back to "Deny."
    • 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 forms. They will not be able to edit the form, or any of its children, unless explicitly overridden with a different setting down the tree.
  4. Click the three-dot menu of the form you wish to manage permissions for, and select Permissions.
  5. Or, if editing a form, click the Actions button, and select Permissions.
  6. From the Permissions screen, select your desired options for each group.
  7. Click Update, to save your changes.
  8. Users will obtain the new roles/privileges on their next successful login. So, if a users is logged in when the permissions were updated, they will have to log out, and then log back in, to see the changes.