You apply permissions to assets individually. 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 to view the content of that asset within the front end of the site.
The system administrators and the root user have access to all assets within the system, regardless of the permissions.
There are three different levels of permissions on an asset:
- Read permission
Users with read permissions can view the contents of an asset. Users need to have at least read permission to view live assets.
- Write permission
Users with write permissions can view and edit an asset. Users with write permission can still view assets that are not live.
Write permission does not grant the ability to; make some status changes on the Details screen, change permissions, or apply a Workflow or Metadata schema.
Users with write permission to the asset can also view the asset changes when it is in a Safe Edit status. This permission includes seeing the differences between the safe edit version of the asset and the live version.
- Admin permission
Users with admin permission for an asset are considered an administrator of that asset. They can 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.
Backend users can be given admin permission to an asset so they can perform all required tasks without the help of a system administrator.
Matrix automatically grants system administrators and the root user this level of access for all assets.
Assets will automatically inherit the permissions applied to the parent asset.
No permissions are applied if no permissions are granted. 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 grant permissions to individuals in that group explicitly. The same is true for roles. If you grant or deny access to a role, all users or user groups assigned that role on that asset will automatically inherit those permissions.
The permission screen on an asset lets you grant or deny either read, write, or admin permission to either the public, a user, a user group, or a role.
Read Asset permissions screen for more information on the Permissions screen including how to cascade permission settings to child assets.
The following are some common permission outcomes on the Permissions screen of an asset:
- Grant public read permission
The public will be able to view the asset’s content from the frontend of your site.
- Grant read permission to a user group containing users
Signed-in users in that user group can view the content on the frontend of your site.
- Grant read permission to a user group containing backend users
Backend users in that user group can view the screens of the asset in the administration interface. However, they will not be able to edit it.
- Deny read permission to a user group containing backend users
Backend users in that user group can see the asset in the asset tree. However, they will not be able to view any of its screens.
- Grant write permission to a user group containing backend users
Backend users in that user group can edit that asset and create child assets.
- Grant admin permission to a user group containing backend users
Backend users in that user group will be considered administrators of the asset.
They can 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
Matrix will ignore this setting. System administrators and the root user have access to all assets within the system, regardless of permissions applied.