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.
To manage user activity, Silva uses a roles approach. Silva has five built-in roles:
Additionally, to restrict access to published content to authenticated users (see Access Restrictions below), there are a number of Viewer roles:
Viewer
Viewer +
Viewer ++
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:
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.
© Copyright 2002-2007 Infrae.
All rights reserved. 
