Standard permissions and roles¶
Technical overview of Plones standard permissions and roles.
The standard permissions can be found in
AccessControl``s and ``Product.CMFCore’s
Here, you will find a short
id (also known as the Zope 3 permission id) and a longer
title (also known as the Zope 2 permission title).
For historical reasons, some areas in Plone use the id, whilst others use the title.
As a rule of thumb:
- Browser views defined in ZCML directive use the Zope 3 permission id;
- Security checks using
zope.security.checkPermission()use the Zope 3 permission id;
add_permissionFTI variable uses the Zope 3 permission id;
rolemap.xmlGenericSetup handler and workflows use the Zope 2 permission title;
- Security checks using
getSecurityManager().checkPermission(), including the methods on the
portal_membershiptool, use the Zope 2 permission title.
The most commonly used permission are shown below. The Zope 2 permission title is shown in parentheses.
- used to control access to the standard view of a content item;
- used to control the ability to delete child objects in a container;
cmf.ModifyPortalContent(Modify portal content)
- used to control write access to content items;
- used to control access to management screens;
cmf.AddPortalContent(Add portal content)
- the standard add permission required to add content to a folder;
cmf.SetOwnProperties(Set own properties)
- used to allow users to set their own member properties’
- typically used as a workflow transition guard to allow users to submit content for review;
cmf.ReviewPortalContent(Review portal content)
- usually granted to the
Reviewerrole, controlling the ability to publish or reject content.
As with permissions, it is easy to create custom roles
rolemap.xml GenericSetup import step – see
CMFPlone’s version of this file for an example), although you should use the standard roles where possible.
The standard roles in Plone are:
- a pseudo-role that represents non-logged in users.
if a permission is granted to Anonymous, it is effectively granted to everyone. It is not possible to grant permissions to non-logged in users without also granting them to logged in ones.
- a pseudo-role that represents logged-in users.
- automatically granted to the creator of an object.
- which represents super-users/administrators.
Almost all permissions that are not granted to
Anonymousare granted to
- Site Manager
- which represents site/administrators. Has permissions needed to fully manage a single Plone site.
- which represents content reviewers separately from site administrators. It is possible to grant the Reviewer role locally on the Sharing` tab, where it is shown as Can review.
- representing “standard” Plone users.
In addition, there are three roles that are intended to be used as local roles only. These are granted to specific users or groups via the Sharing tab, where they appear under more user friendly pseudonyms.
- Reader, aka Can view,
- confers the right to view content. As a rule of thumb, the Reader role should have the View and Access contents information permissions if the Owner roles does.
- Editor, aka Can edit,
- confers the right to edit content. As a rule of thumb, the Editor role should have the Modify portal content permission if the Owner roles does.
- Contributor, aka Can add,
- confers the right to add new content.
As a rule of thumb,
the:guilabel: Contributor role should have the Add:guilabel: portal content permission
and any type-specific add permissions globally
(i.e. granted in
rolemap.xml), although these permissions are sometimes managed in workflow as well.