About objects permissions
Contents
Object permissions – i.e. what a user can do on a specific object, e.g. an article, a page, an edition etc. – are shown in a matrix of permissions (Read, Write, Place, Send, RefR(ead), RefW(rite), Delete, Ref Delete) and access classes (Normal, Protected, Special, Content).
See also System permissions that specify what users can do system-wide.
An example of the object permissions matrix
Every item can be granted (green icon with +), denied (red icon with -) or undefined (gray icon).
Permissions groups
The permissions are split in the following groups:
•Access to objects as a whole (‘Delete’ and ‘RefDelete’)
•Access to object attributes (ReadXXXX, WriteXXXX);
•Access to referencing objects attributes (RefReadXXX, RefWriteXXX);
•Permission on referenced objects (PlaceInXXXX and SendFromXXXX).
Note that the fact that ‘read’ and ‘write’ permissions for each access class allow to grant or deny access to different attributes of an object – e.g. allow a certain user to modify the meta-data (caption, source etc.) of a image, but not the image itself.
ReadNormal, ReadProtected, ReadSpecial, ReadContent Read the value of the attributes of the object with the corresponding access class – e.g. ‘ReadNormal’ allows reading all the attributes whose type has the ‘normal’ access class. An example: in case of a folder, they apply on the folder itself and not on the content in the folder. WriteNormal, WriteProtected, WriteSpecial, WriteContent Write (i.e. modify) the value of the attributes of the object with the corresponding access class – e.g. ‘WriteContent’ allows the modification of all the attributes whose type has the ‘content’ access class. An example: in case of a folder, they apply on the folder itself and not on the content in the folder. Delete Logically delete (‘spike’) the object. An example: in case of a folder, it applies on the folder itself and not on the content in the folder. RefReadNormal, RefReadProtected, RefReadSpecial, RefReadContent Same as ReadXXX but applies to the referencing objects instead that to the object itself – e.g. if a user has ‘RefReadNormal’ permission on an object, he will be able to read the ‘normal’ attributes of objects referencing that object. An example: in case of a folder, they apply on the folder content but not on the folder itself. RefWriteNormal, RefWriteProtected, RefWriteSpecial, RefWriteContent Same as WriteXXXX but they apply to the referencing objects instead that the object itself. An example: in case of a folder, they apply on the folder content but not on the folder itself. RefDelete Logically delete (‘spike’) referencing objects. An example: in case of a folder, it applies on the folder content but not on the folder itself. PlaceInNormal, PlaceInProtected, PlaceInSpecial, PlaceInContent Allow another object with the corresponding access class to reference this object – e.g. ‘PlaceInProtected’ allows objects whose type has the ‘protected’ access class to reference this object. SendFromNormal, SendFromProtected, SendFromSpecial, SendFromContent Allow another object with the corresponding access class to no longer reference this object (or to be deleted) – e.g. ‘SendFromNormal’ allows objects whose type has the ‘normal’ access class to no longer reference this object. |
To better explain the use of the PlaceInXXXX/SendFromXXXX group of permissions, consider the following: some object types are indeed ‘containers’ – e.g. a folder; when an object references one of these ‘containers’, it can be considered as being ‘inside’ the container (e.g. a document referencing a folder is "inside" a folder). In this situation, the PlaceInXXXX permissions applied to the container, control which user can put items inside the container; the SendFromXXX permissions applied to the container, control which user can remove objects from the container. The fact that there is one ‘place’ and one ‘send’ permissions for each access class allows to differentiate the access by object type: if a container object can be referenced by two different object types (e.g. a folder that can contain document and image objects), you can assign different access classes to the two types (e.g. ‘normal’ for document and ‘special’ for image) and access permissions to the containers so that certain users could move around images but not documents or vice-versa. Note finally that the act of logically deleting (deleting) an object is considered as moving the object outside a container (if any) – and so to be successful the user requesting the deletion must have "send from" permission on the container object(s) beside "delete" permission on the object itself. |
It is recommended to be careful when denying permissions explicitly, especially on folders. This may lead to locking out also member of the Administrators group. Generally speaking, if you can achieve the desired result without using explicit denial, it's a better solution. It is recommended to use explicit denial only in special cases, e.g. when you create a group whose members will be kept off specific operations. |
See also