Permissions are applied on an asset per asset basis. An administrator will decide who has access to view and edit an asset by setting these permissions. For example, an administrator can grant Public Read Permission to an asset so the public can view the content of that asset within the Frontend of the Site. The System Administrators and the Root User have access to all assets within the system, regardless of the level of permissions that been applied.

Permission Types

There are three different levels of permissions on an asset:

Read Permission

If a user has Read Permission to an asset, they are able to view the content of the asset. The Public User and Users need to at least have Read Permission in order to view Live assets on the Site.

Write Permission

If a user has Write Permission for an asset, they are able to view and edit the asset. Users with Write Permission can still view the asset even if it is not Live. Having Write Permission does not allow you to perform certain tasks on the asset including making certain Status changes on the Details screen, changing the Permissions and applying a Workflow or Metadata Schema. A User needs to at least have Write Permission to an asset in order to edit it.

Users with Write Permission to the asset can also view the changes of the asset when it's in a Safe Edit status including seeing the differences between the Safe Edit version of the asset and the Live version.

Admin Permission

If a user has Admin Permission for an asset they are considered an administrator of that asset. They are able to perform all tasks for that asset including editing its content, changing the Status on the Details screen, changing the Permissions and applying a Workflow or Metadata Schema.

If a Backend User is a trusted user of the system, they can be given Admin Permission to an asset so they can perform all required tasks without the help of a System Administrator. A System Administrator and the Root User are automatically given this level of access for all assets in the system.

Granting and Denying Permissions

When an asset is created, it will automatically inherit the permissions that have been applied to its parent asset. If no permissions have been granted, then no permissions will be applied. You can grant either Read, Write or Admin permission to either a User, User Group or Role. You can also deny Read, Write or Admin permissions to a particular asset, to prevent a User, a group of users or a Role from accessing a particular asset.

If you choose to grant or deny access to a User Group, all users in that group will automatically inherit those permissions. You do not have to explicitly grant permissions to individual users in that group. The same is applied for Roles. If you grant or deny access to a Role, all users or User Groups that have been assigned the Role on that asset will automatically inherit those permissions.

Applying Permissions

The Permission screen on an asset allows you to grant or deny either Read, Write or Admin Permission to either the Public, a user, a User Group, or a Role. Read the Asset permissions screen manual for more information on the Permissions screen including how to cascade permissions to child assets.

Common Permission Outcomes

Outlined below are some common permission outcomes that can be achieved on the Permissions screen of an asset.

• Grant Public Read Permission: The public will be able to view the content of the asset within the Frontend of your Site.
• Grant Read Permission to a User Group containing Users: The Users in that User Group need to be logged into your Site in order to view the content within the Frontend of your Site.
• Grant Read Permission to a User Group containing Backend Users: The Backend Users in that User Group will be able to view the screens of the asset in the Administration Interface but they will not be able to edit it.
• Deny Read Permission to a User Group containing Backend Users: The Backend Users in that User Group will be able to see the asset in the Asset Map but they will not be able to view any of its screens.
• Grant Write Permission to a User Group containing Backend Users: The Backend Users in that User Group will be able to edit that asset as well as create child assets.
• Grant Admin Permission to a User Group containing Backend Users: The Backend Users in that User Group will be considered administrators of the asset. They will be able to perform all functions on the asset including making the asset Live, changing permissions and applying Metadata and Workflow Schemas.
• Deny Admin Permission to a System Administrator or the Root User: Squiz Matrix will ignore this setting. System Administrators and the Root User have access to all assets within the system, regardless of the level of permissions that been applied.