Default Permissions Model Reference

cancel
Showing results for 
Search instead for 
Did you mean: 

Default Permissions Model Reference

resplin
Intermediate
0 0 6,772

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 cmSmiley Surprisedbject)

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.

cmSmiley Surprisedbject


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 cmSmiley Surprisedbject but with no Administrator permission group.


cmSmiley Surprisedwnable


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.