From 1.4, previously permission groups were not prefixed by _ and there were no simple permission groups so that more complex permission groups were easy to build.
For those with RBAC experience, you may think of stuff starting with _ as a permission and the rest as roles. However subjects (people, groups and dynamic subjects) can be assigned to either. The checks around service can also use any. So it is not traditional RBAC.
The underlying permissions are defined here. These are:
Restrict read access to the properties of a node. Access to content is controlled separately. All properties have the same access restrictions.
Restrict read access to children. The permissions set on individual children will be respected. If this permission is not granted you can not see any children when browsing. You could find children to which you have access during a search. To view a node there is no requirement that you can see its parent. This constraint can be added in the configuration.
Restrict write access to all properties of a node. Access to content is controlled separately. All properties have the same access restrictions.
Restrict access to read all content for a node.
Restrict access to create and update all content for a node.
Restrict access to execute content.
Restrict access to delete a node. Currently there is no check that you have the right to delete all the children of the node or that you can delete children from parent. This support is available and is commented out in the configuration. Checking that all children can be deleted upfront is expensive.
Restrict access to deleting children of a node (as opposed to removing secondary links to other nodes)
Restrict access to creating new child nodes (primary associations).
Restrict access to create secondary associations to already existing nodes.
Restrict access to delete non child associations for a node.
Restrict access to read non child associations for a node.
Retrict access to create non child associations for a node.
Restrict access to read permissions on a node.
Restrict access to write permissions on a node.
These are grouped into simple permission groups, which themselves can be grouped into more complex groups (see cmbject)
Simple groups are normally used to control the access to methods on public services. This is clear as they translate by convention to a single permission.
A permission group that allows all other permissions.
Granted from _ReadProperties.
Granted from _ReadChildren.
Granted from _WriteProperties.
Granted from _ReadContent.
Granted from _WriteContent.
Granted from _ExecuteContent.
Granted from _DeleteNode.
Granted from _DeleteChildren.
Granted from _CreateChildren.
Granted from _LinkChildren.
Granted from _DeleteAssociations.
Granted from _ReadAssociations.
Granted from _CreateAssociations.
Granted from _ReadPermissions.
Granted from _ChangePermissions.
There are some common groupings of permissions for CRUD operations on nodes.
Combines ReadProperties, ReadChildren, and ReadContent.
Write (Update in CRUD)
Combines WriteProperties and WriteContent.
Combines DeleteNode and DeleteChildren.
AddChildren (Create in CRUD)
Combines CreateChildren and LinkChildren. (Link is not strictly part of create in the CRUD sense)
Has all permissions. For backward compatibility.
The coordinator gets all permissions and permission groups defined.
Combines Editor and Contributor permission groups.
Includes the Consumer permission group and adds AddChildren and CheckOut.
They will, by default own anything they create and have the ROLE_OWNER authority.
Include the Consumer permission group and adds Write and CheckOut.
Includes ReadProperties, ReadChildren, WriteProperties, ReadContent, DeleteChildren, CreateChildren, LinkChildren, DeleteAssociations and CreateAssociations.
As cmbject but with no Administrator permission group.
Restrict setting permisisons on a node. This permissions also requires that _WriteProperties is also granted. It is not implied by having _WriteProperties.
Simple Permission Groups
Granted from ;_SetOwner
Complex Permission Groups
Restrict access to lock a node.
Restrict access to unlock a node.
Simple Permission Groups
Granted from _Lock
Granted from _Unlock
Complex Permission Groups
These apply to all nodes regardless of where they are in the repository.
'FullControl' granted to 'ROLE_ADMINISTRATOR'
Admin users can do anything
'FullControl' granted to 'ROLE_OWNER'
The owner (as defined by the ownable aspect, or, if the aspect is not present the node creator) is allowed all rights. This interacts with contributor for cm:content. They only need the right to create content in the default set up; all other rights come from the fact that they own the nodes they create.
'Unlock' granted to 'ROLE_LOCK_OWNER'
The owner of a lock can always release the lock.
'CheckIn' granted to 'ROLE_LOCK_OWNER'
The owner of a lock can checkin a document - underneath the cover it holds a lock.
'CancelCheckOut' granted to 'ROLE_LOCK_OWNER'
The owner of a lock can cancel a check out of a document - underneath the cover it holds a lock.