|Version 2 (modified by 15 months ago) ( diff ),|
Cinnamon permission configuration
Cinnamon has a detailed permission system that is organized using Access Control Lists (ACLs). Every repository item (objects and folders) has exactly one ACL attached to it. ACLs are inherited from the folder an object or folder is created in. Versioned objects inherit the ACL from their predecessor.
ACLs can also be applied to objects by lifecycle states. The lifecycle state configuration allows to configure a specific ACL with a lifecycle state which is applied to the object when the new lifecycle state is reached. This does not apply to folders, because folders don't have a lifecycle. Using ACLs switched by lifecycles is, for example, useful to set up review lifecycles. This way, it is possible to allow authors to edit an object while it is in the state of authoring, remove write access to the object once it is in review state, and lock it completely when it is released, so that any changes can only be implemented by versioning the object.
As the name says, an Access Control List is a list of entries that control access to an object or folder. An ACL must at least have one entry to make any sense, and there can be as many entries as required. Every entry is associated with a so-called accessor which is one of the following:
- A specific user
- A user group
- An alias, particularly
_users, if certain permissions should be active for every user (for example, read permission on global configuration objects).
ACLs are configured in the administration web frontend.
The basic steps are:
- Select or create an ACL
- Select the accessor whose permissions should be changed
- Toggle the permission states by clicking on the red or green icons.
The following permissions are known to Cinnamon:
|Allow the user to add a new relation pointing to a child object (for example, a referenced image). Authors editing modular content should have this permission, otherwise they can't insert new children like images or cross-references to other objects.|
|Allow the user to add a new parent relation - in other words, allow the user to create a relation with this object as a child. To be allowed to add a relation between two objects, the user must have both |
|This permission is required to see an object (without necessarily any further permissions to do anything with the object). If a user has no browse permission on an object, it is neither returned in the list of folder content nor as a search result. Practically, the object behaves to the user as if it wouldn't exist.|
|Same as |
|Permission to change the lifecycle state on an object. The lifecycle state may change the ACL on the object even though the user has no explicit permission to change the ACL (|
|This permission is required on a folder to allow creation of a subfolder inside.|
|This permission is required on a folder to allow creation of a object inside.|
|Allow the user to delete a folder.|
|Allow the user to delete an object.|
|Allow the user to set folder metadata (name, parent folder, owner, folder type, folder custom metadata). Folders do not have a lock status (as in objects), therefore, the |
|Permission to lock and unlock an object (folders do not have a lock status). Lock status is required for changing system or custom metadata, changing the lifecycle state, changing the ACL or writing the content of an object.|