Changes between Version 1 and Version 2 of Public/Docs/CinnamonPermissions


Ignore:
Timestamp:
Oct 27, 2020, 9:57:20 AM (3 years ago)
Author:
Boris Horner
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Public/Docs/CinnamonPermissions

    v1 v2  
    1818The following permissions are known to Cinnamon:
    1919||**Permission** ||**Description** ||
    20 ||{{{}}} ||foo ||
     20||{{{_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. ||
     21||{{{_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. ||
     22||{{{_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. ||
     23||{{{_browse_folder}}} ||Same as {{{_browse}}}, but for folders instead of objects. ||
     24||{{{_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. ||
     25||{{{_create_folder}}} ||This permission is required on a folder to allow creation of a subfolder inside. ||
     26||{{{_create_inside_folder}}} ||This permission is required on a folder to allow creation of a object inside. ||
     27||{{{_delete_folder}}} ||Allow the user to delete a folder. ||
     28||{{{_delete_object}}} ||Allow the user to delete an object. ||
     29||{{{_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. ||
     30||{{{_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, changing the ACL or writing the content of an object. ||
     31||{{{_move}}} || ||
     32||{{{_read_object_content}}} || ||
     33||{{{_read_object_custom_metadata}}} || ||
     34||{{{_read_object_sysmeta}}} || ||
     35||{{{_remove_child_relation}}} || ||
     36||{{{_remove_parent_relation}}} || ||
     37||{{{_set_acl}}} || ||
     38||{{{_version}}} || ||
     39||{{{_write_object_content}}} || ||
     40||{{{_write_object_custom_metadata}}} || ||
     41||{{{_write_object_sysmeta}}} || ||