| | 1 | = Cinnamon permission configuration |
| | 2 | 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. |
| | 3 | |
| | 4 | 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. |
| | 5 | |
| | 6 | 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: |
| | 7 | * A specific user |
| | 8 | * A user group |
| | 9 | * An alias, particularly {{{_users}}}, if certain permissions should be active for every user (for example, read permission on global configuration objects). |
| | 10 | |
| | 11 | ACLs are configured in the administration web frontend. |
| | 12 | |
| | 13 | The basic steps are: |
| | 14 | * Select or create an ACL |
| | 15 | * Select the accessor whose permissions should be changed |
| | 16 | * Toggle the permission states by clicking on the red or green icons. |
| | 17 | |
| | 18 | The following permissions are known to Cinnamon: |
| | 19 | ||**Permission** ||**Description** || |
| | 20 | ||{{{}}} ||foo || |
