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:

Permission	Description
_add_child_relation	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.
_add_parent_relation	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 _add_child_relation on the parent and _add_parent_relation on the child. This permission should typically be active rather liberally, even on released objects, because otherwise they can't be referenced, or re-used.
_browse	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.
_browse_folder	Same as _browse, but for folders instead of objects.
_change_lifecycle_state	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 (_set_acl). Since lifecycle states can only be changed when an object is locked, users must also have _lock permission on the object to benefit from this permission. The _change_lifecycle_state permission is useful to configure the permission to edit the metadata of an object and the right to change its state independently.
_create_folder	This permission is required on a folder to allow creation of a subfolder inside.
_create_inside_folder	This permission is required on a folder to allow creation of a object inside.
_delete_folder	Allow the user to delete a folder.
_delete_object	Allow the user to delete an object.
_edit_folder	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 _lock permission is not required to change folder metadata.
_lock	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, moving an object, changing the ACL or writing the content of an object.
_move	Permission to move an object or folder to a different parent folder.
_read_object_content	Permission to read the content file of an object.
_read_object_custom_metadata	Permission to read the custom metadata of an object.
_read_object_sysmeta	Permission to read the system metadata (name, ACL, owner etc.) of an object.
_remove_child_relation	Allow the user to remove an exiting relation pointing to a child object (for example, a referenced image). Authors editing modular content should have this permission, otherwise they can't remove children like images or cross-references to other objects.
_remove_parent_relation	Allow the user to remove a new parent relation - in other words, allow the user to remove a relation with this object as a child. To be allowed to remove a relation between two objects, the user must have both _remove_child_relation on the parent and _remove_parent_relation on the child. This permission should typically be active rather liberally, even on released objects, because otherwise re-use is impossible.
_set_acl	Permission to change the ACL on an object. Since ACLs can only be changed when an object is locked, users must also have _lock permission on the object to benefit from this permission.
_version	Permission to create a new version of an object. Note that this permission can be used independently on the various _write_object_* permissions, so by means of ACLs, users can be allowed to overwrite and version an object, overwrite only, version only or none.
_write_object_content	Permission to write content on an object. Since content can only be changed when an object is locked, users must also have _lock permission on the object to benefit from this permission.
_write_object_custom_metadata	Permission to write custom metadata on an object. Since custom metadata can only be changed when an object is locked, users must also have _lock permission on the object to benefit from this permission.
_write_object_sysmeta	Permission to write system metadata (name, ACL, owner etc.) on an object. Since system metadata can only be changed when an object is locked, users must also have _lock permission on the object to benefit from this permission.