Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
Authorization
The default permissions model defines the following permissions.
sys:base
Base permissions
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:
- _ReadProperties
- Restrict read access to the properties of a node. Access to content is controlled separately. All properties have the same access restrictions.
- _ReadChildren
- 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.
- _WriteProperties
- Restrict write access to all properties of a node. Access to content is controlled separately. All properties have the same access restrictions.
- _ReadContent
- Restrict access to read all content for a node.
- _WriteContent
- Restrict access to create and update all content for a node.
- _ExecuteContent
- Restrict access to execute content.
- _DeleteNode
- 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.
- _DeleteChildren
- Restrict access to deleting children of a node (as opposed to removing secondary links to other nodes)
- _CreateChildren
- Restrict access to creating new child nodes (primary associations).
- _LinkChildren
- Restrict access to create secondary associations to already existing nodes.
- _DeleteAssociations
- Restrict access to delete non child associations for a node.
- _ReadAssociations
- Restrict access to read non child associations for a node.
- _CreateAssociations
- Retrict access to create non child associations for a node.
- _ReadPermissions
- Restrict access to read permissions on a node.
- _ChangePermissions
- Restrict access to write permissions on a node.
Simple groups
These are grouped into simple permission groups, which themselves can be grouped into more complex groups (see cm
bject)
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.
- FullControl
- A permission group that allows all other permissions.
- ReadProperties
- Granted from _ReadProperties.
- ReadChildren
- Granted from _ReadChildren.
- WriteProperties
- Granted from _WriteProperties.
- ReadContent
- Granted from _ReadContent.
- WriteContent
- Granted from _WriteContent.
- ExecuteContent
- Granted from _ExecuteContent.
- DeleteNode
- Granted from _DeleteNode.
- DeleteChildren
- Granted from _DeleteChildren.
- CreateChildren
- Granted from _CreateChildren.
- LinkChildren
- Granted from _LinkChildren.
- DeleteAssociations
- Granted from _DeleteAssociations.
- ReadAssociations
- Granted from _ReadAssociations.
- CreateAssociations
- Granted from _CreateAssociations.
- ReadPermissions
- Granted from _ReadPermissions.
- ChangePermissions
- Granted from _ChangePermissions.
Complex Groups
There are some common groupings of permissions for CRUD operations on nodes.
- Read
- Combines ReadProperties, ReadChildren, and ReadContent.
- Write (Update in CRUD)
- Combines WriteProperties and WriteContent.
- Delete
- Combines DeleteNode and DeleteChildren.
- AddChildren (Create in CRUD)
- Combines CreateChildren and LinkChildren. (Link is not strictly part of create in the CRUD sense)
- Execute
- Just ExecuteContent.
cm
bject
Complex Groups
- Administrator
- Has all permissions. For backward compatibility.
- Coordinator
- The coordinator gets all permissions and permission groups defined.
- Collaborator
- Combines Editor and Contributor permission groups.
- Contributor
- Includes the Consumer permission group and adds AddChildren and CheckOut.
- They will, by default own anything they create and have the ROLE_OWNER authority.
- Editor
- Include the Consumer permission group and adds Write and CheckOut.
- Consumer
- Includes Read
- RecordAdministrator
- Includes ReadProperties, ReadChildren, WriteProperties, ReadContent, DeleteChildren, CreateChildren, LinkChildren, DeleteAssociations and CreateAssociations.
cm:folder
Complex Groups
As cm
bject but with no Administrator permission group.
cm
wnable
Base Permissions
- _SetOwner
- 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
- SetOwner
- Granted from ;_SetOwner
Complex Permission Groups
- TakeOwnership
- Includes SetOwner.
cm:lockable
Base Permissions
- _Lock
- Restrict access to lock a node.
- _Unlock
- Restrict access to unlock a node.
Simple Permission Groups
- Lock
- Granted from _Lock
- Unlock
- Granted from _Unlock
Complex Permission Groups
- CheckOut
- Includes Lock.
- CheckIn
- Includes Unlock.
- CancelCheckOut
- Includes Unlock.
Global permissions
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.