Roles and permissions
Overview
Silva comes with an advanced user role management system; it allows the secure delegation of tasks throughout a Silva website.
Silva allows responsibility and work to be delegated so that it cascades down the hierarchy of an organization. Hundreds of users can be managed in a scalable way, avoiding single-person bottlenecks for content management.
The Roles concept
To manage user activity, Silva uses a roles approach. Silva has five built-in roles:
- Manager
- Chief Editor
- Editor
- Author
- Reader
Additionally, to restrict access to public content (see Access Restrictions below), there are a number of Viewer roles:
- Viewer
- Viewer
- + Viewer ++
This setup allows responsibility or work to be delegated so it cascades down the hierarchy of the organization. A Manager creates a few Chief Editors, a Chief Editor creates a number of Editors, Authors, Readers and so on. Hundreds of users can be managed easily.
Role Flexibility
A person can have different roles in different locations within the content tree. A person could be a Chief Editor in one area but only a Reader in another. A person can even be a Manager somewhere but have no access, not even viewing access to published information, in another area.
The Silva roles and their privileges are:
A Reader is allowed to:
Read and preview documents.
Copy content to the clipboard. This is useful if a user is an Author elsewhere and wants to (ghost) copy content.
An Author is allowed to:
Create, edit, and delete unpublished documents
Request approval for publication for content.
Revoke approval of previously approved (but not published) content.
Create a new editable version of already published content to prepare new content. This new version can however not be published without Editor approval.
choose to edit from a range of document versions.
An Editor is allowed to:
Approve and publish content, e.g. make it available for the public.
Define and change the time frame within which content will be published.
Close published content.
Delete published content, i.e. close the content and delete it.
Activate subscription.
A Chief Editor is allowed to:
Grant/revoke roles from/to users and groups, including the Editor, Author and Reader roles. Chief Editor is allowed to create new Editors, Author and Readers in particular locations. However the Manager has to join new people to the site first.
Create and edit groups.
Determine the types of addable content.
Delegate request for approval messages sent via email.
A Manager (has the same rights as a Zope manager):
A manager can create new Chief Editors and other Managers by assigning those roles to users in a location.
This role is allowed to do lower level operations via the Zope Management Interface, like add layout page templates or create external sources.
Add new users to the site in the ZMI via the User Folder or LDAP etc.
Role hierarchy
Silva roles are in a hierarchy, i.e. the Manager can play the Chief Editor role, who can play an Editor role, etc.
Setting up an Intranet
The Authenticated and Viewer roles can be used to create a closed off (Intranet) area within a Silva site. In order to view published content in that area visitors must be at least authenticated and/or have the Viewer role or higher assigned to them in this area.
Typically for easier management a viewer role is assigned to a group of users instead, and then all members of this group are allowed to enter this area.
Sometimes, in a section of a site that is already restricted, there needs to be further restrictions set to limit access to a subset of that group. This can be done by using the Viewer + and Viewer ++ roles. Up to two levels of more restricted access is possible. See restricting public access.
Structuring access by Folder/Publication
Role assignment works following the principle of acquisition, where items inherit characteristics from their physical parents. An example of this can also be seen in the presentation of a Silva website where a branch of a site can have a different layout and style. When the style in a branch is altered, the new presentation is automatically acquired by all items in the branch.
Silva’s role assignment works the same way. Roles do not have to be granted to a user per document (unless desired) but can be granted in a folder, which affects all items, including documents and underlying folders.
If somebody is given a role in a Publication or Folder, it is not possible to withdraw that role on a lower level. This should be kept in mind when setting up the content tree structure.
If Authors should not be able to edit each other’s content, they should be assigned roles in different branches of the tree. If on the other hand an Author needs access to the whole tree this is possible as well; a Chief Editor with rights on the top of the tree can assign the Author role to someone in the top of the Silva tree (Silva root).
Setting up users so Silva can find them
It is the task of a site Manager to set up Silva and its users, while Chief Editors are responsible for assigning roles to users. Chief Editors are not able to create users themselves.
In a simple Silva setup, users are created and deleted in the standard Zope user folder (acl_users) by a site manager with Zope management access. In a more advanced setup there is usually an external system that handles authentication.
When creating users in the Zope Management Interface in acl_users, do not assign them a role there. Assigning a role there would result in them having this role throughout the Silva instance, which is usually not the intent. In addition, there is no way to manage this setting from within the Silva user interface, only from the Zope Management Interface.
In more sophisticated Silva setups other user folders types can be used, for instance the LDAPUserFolder. Using a Silva Extension a Manager can set up Silva so that it retrieves users and user information from an external system. This way it is possible to work with large quantities of users. See the Adding Users for Managers guide for more information.