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

Timestamp:

Oct 27, 2020, 10:06:59 AM (4 years ago)

Author:

Boris Horner

Comment:

—

Public/Docs/CinnamonPermissions

@@ -22 +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. ||
 ||{{{_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. ||
+||{{{_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. ||
@@ -28 +28 @@
 ||{{{_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, changing the ACL or writing the content of an object. ||
-||{{{_move}}} || ||
-||{{{_read_object_content}}} || ||
-||{{{_read_object_custom_metadata}}} || ||
-||{{{_read_object_sysmeta}}} || ||
-||{{{_remove_child_relation}}} || ||
-||{{{_remove_parent_relation}}} || ||
-||{{{_set_acl}}} || ||
-||{{{_version}}} || ||
-||{{{_write_object_content}}} || ||
-||{{{_write_object_custom_metadata}}} || ||
-||{{{_write_object_sysmeta}}} || ||
+||{{{_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. ||