Roles and permissions
Silva comes with an advanced user role management system; it allows the secure delegation of tasks throughout a Silva website.
Silva allows responsibility or work to be delegated so that it cascades down the hierarchy of an organization. Hundreds of users can be managed in a scalable way there is no need for a single-person bottleneck for publication of documents or role assignment.
|Roles within the Silva Environment|
|Action||Reader ||Author ||Editor ||Chief Editor ||Manager |
|create, edit, delete|
|submit for publication||+||+||+||+|
|create editable version|
of published content
|approve, publish content||+||+||+|
|define and change time frame||+||+||+|
|close, delete published content, activate subscriptions||+||+||+|
|assign new editors, authors, readers, viewers, set up groups, activate addable types of content, delegate email request for approval messages||+||+|
|ZMI actions, add users, add External Sources, create Code Sources, refresh content, configure services||+|
|Access for Public Pages|
|Action||Everybody ||Authenticated ||Viewer ||Viewer+||Viewer++ |
|view public content||+||+||+||+||+|
|view authenticated content||+||+||+||+|
|view restricted authenticated content||+||+||+|
|view IP restricted content|| optional || optional || optional || optional || optional |
- Chief Editor
Additionally, to restrict access to published content to authenticated users (see Access Restrictions below), there are a number of Viewer roles:
The 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 in a scalable way; there is no need for a single person bottleneck for both publication of documents or role assignment.
A person can have different roles in different locations within Silva content. 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:
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.
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.
restrict public access.
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.
The Viewer role 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 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, a section of a site that is already restricted to people with the Viewer role there needs to be restricted to a subset of people again. This can be done by using the Viewer + and Viewer ++ roles, so up to two levels of more restricted access is possible. See restricting public access.
Silva roles are in a hierarchy, i.e. the Manager can play the Chief Editor role, who can play an Editor role, etc.
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; 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 publication 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).
It is the task of a site Manager to set up Silva and its users. Chief Editors are able to assign roles to users known by the system, but are not able to create the 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.
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 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 LDAP server. This way it is possible to work with very large quantities of users. See the Managers Adding Users guide for more information.