Standard permissions and roles¶
Technical overview of Plones standard permissions and roles.
The standard permissions can be found in
permissions.zcml. Here, you will find a short
(also known as the Zope 3 permission id) and a
(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
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 role 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 role 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 role of
thumb, the:guilabel: Contributor role
should have the
Add:guilabel: portal content permission and
any type-specific add permissions globally (i.e. granted
rolemap.xml), although these permissions are sometimes managed in workflow as well.