= 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 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. ||