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
type if the user has the
session.py, we update the
class with the following:
from zope.security import checkPermission class View(BrowserView): def canRequestReview(self): return checkPermission('cmf.RequestReview', self.context)
And in the
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, using the
property. This can be changed through the web or in the
GenericSetup import step for the content type.
To make the
type use our new permission, we modify the
Protecting views and forms¶
Access to views and other browser resources (like viewlets
or portlets) can be protected by permissions, either using
attribute on ZCML statements like:
<browser:page ... permission="zope.Public" ... />
We could also use the special
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. The
directives are found in the
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
object in a text field, so that the creator of the
can choose the available tracks.
First, we add this to the
form.widget(tracks=TextLinesFieldWidget) tracks = schema.List( title=_(u"Tracks"), required=True, default=, value_type=schema.TextLine(), )
is used to edit a list of text lines in a text area. It is
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
will be the
Program, but on the edit form, it will be the
Session, so we need to check the parent) and uses its
variable as the vocabulary.
Next, we add a field to the
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
permission should be able to edit tracks for a session.
For everyone else, the field will be hidden in the edit