Setting up add permissions, view permissions and field view/edit permissions
Plone’s security system is based on the concept of permissions protecting operations (like accessing a view, viewing a field, modifying a field, or adding a type of content) that are granted to roles, which in turn are granted to users and/or groups. In the context of developing content types, permissions are typically used in three different ways:
- A content type or group of related content types often has a custom add permission which controls who can add this type of content.
- Views (including forms) are sometimes protected by custom permissions.
- Individual fields are sometimes protected by permissions, so that some users can view and edit fields that others can’t see.
It is easy to create new permissions. However, be aware that it is considered good practice to use the standard permissions wherever possible and use workflow to control which roles are granted these permissions on a per-instance basis.
For more basic information on permissions and how to create custom permissions read the Security Section in the Plone documentation.
Performing permission checks in code¶
It is sometimes necessary to check permissions explicitly in code, for example in a view. A permission check always checks a permission on a context object, since permissions can change with workflow.
Never make security dependent on users’ roles directly. Always check for a permission, and assign the permission to the appropriate role or roles.
As an example,
let’s display a message on the view of a
if the user has the
session.py, we update the
View class with the following:
from zope.security import checkPermission class View(BrowserView): def canRequestReview(self): return checkPermission('cmf.RequestReview', self.context)
And in the
session_templates/view.pt template, we add:
<div class="discreet" tal:condition="view/canRequestReview" i18n:translate="suggest_review"> Please submit this for review. </div>
Content type add permissions¶
Dexterity content types’ add permissions are set in the FTI,
This can be changed through the web
or in the GenericSetup import step for the content type.
To make the
Session type use our new permission, we modify the
add_permission line in
Protecting views and forms¶
Access to views and other browser resources (like viewlets or portlets)
can be protected by permissions, either using the
on ZCML statements like:
<browser:page ... permission="zope.Public" ... />
We could also use the special
zope.Public permission name to make the view accessible to anyone.
Protecting form fields¶
Individual fields in a schema may be associated with a read permission and a write permission. The read permission is used to control access to the field’s value via protected code (e.g. scripts or templates created through the web) and URL traversal, and can be used to control the appearance of fields when using display forms (if you use custom views that access the attribute directly, you’ll need to perform your own checks). Write permissions can be used to control whether or not a given field appears on a type’s add and edit forms.
In both cases,
read and write permissions are annotated onto the schema using directives similar to those we’ve already seen for form widget hints.
write_permission() directives are found in the plone.autoform package.
If XML-schemas are used for defintion see Dexterity XML: security attributes.
Simple example protecting a field to be readable for Site Administrators only:
from zope import schema from plone.supermodel import model from plone.autoform.directives import read_permission class IExampleProtectedInformation(model): read_permission(info='cmf.ManagePortal') write_permission(info='cmf.ManagePortal') info = schema.Text( title=_(u"Information"), )
As a complex example, let’s add a field for Session reviewers to record the track for a session.
We’ll store the vocabulary of available tracks on the parent
Program object in a text field,
so that the creator of the
Program can choose the available tracks.
First, we add this to the
IProgram schema in
form.widget(tracks=TextLinesFieldWidget) tracks = schema.List( title=_(u"Tracks"), required=True, default=, value_type=schema.TextLine(), )
TextLinesFieldWidget is used to edit a list of text lines in a
text area. It is imported as:
from plone.z3cform.textlines.textlines import TextLinesFieldWidget
Next, we’ll add a vocabulary for this to
from Acquisition import aq_inner, aq_parent from zope.component import provider from zope.schema.interfaces import IContextSourceBinder from zope.schema.vocabulary import SimpleVocabulary ... @provider(IContextSourceBinder) def possibleTracks(context): # we put the import here to avoid a circular import from example.conference.program import IProgram while context is not None and not IProgram.providedBy(context): context = aq_parent(aq_inner(context)) values =  if context is not None and context.tracks: values = context.tracks return SimpleVocabulary.fromValues(values)
This vocabulary finds the closest
(in the add form, the
context will be the
but on the edit form, it will be the
so we need to check the parent)
and uses its
tracks variable as the vocabulary.
Next, we add a field to the
ISession interface in the same file and
protect it with the relevant write permission:
write_permission(track='example.conference.ModifyTrack') track = schema.Choice( title=_(u"Track"), source=possibleTracks, required=False, )
With this in place, users with the
example.conference: Modify track
permission should be able to edit tracks for a session. For everyone
else, the field will be hidden in the edit form.