Silva comes with an advanced user management system. For users who have
been granted access, the system allows control of what actions they are
allowed to perform, as well on which items they are allowed to perform
those actions.
In the Access Screen Chief Editors and Managers have the ability to assign actions.
Fig. 1 Access screen.
(see also Roles and Permissions)
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.
Role Flexibility
A user can have different roles in different locations within Silva content. A user could be a Chief Editor in one area but only a Reader in another. A user 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 ChiefEditor role, who can play an Editor role, etc.
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 Access Restrictions below.
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 therein, 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 site 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 SiteManager documents for more information.
A user is not allowed to enter the Silva environment or perform any actions in the SMI unless the user has the appropriate role assigned for the location the user wants to access. Managing such role assignments is described in this section. Only Chief Editors and Managers are allowed to manage role assignments, in the Access screen.
In order to add a role to a user, the first task is to select the user so that a role can be assigned to them. Users are first placed on the ‘clipboard‘(Fig.1). This is done in the Lookup screen. In top right of the Access screen is the user clipboard, which contains a lookup users button. This brings you to the Lookup screen where users can be selected and placed on the clipboard.
In the user search area, type the name or part of the name of the user you want to find and click the search button (alt-s). The system will now list all users which match, with some extra information like an email address if available.
Select the users you want to assign roles to during this session using the checkbox in front of their name, and click the add to clipboard button. The selected users will now appear in the user clipboard area to the right.
You can now repeat this action and look up more users if desired, until all the users you want to assign roles to later are on the clipboard.
The next step is to press the use clipboard button in the user clipboard area. You will now be returned to the Access tab, with the selected users on your clipboard.
You are now ready to assign roles to the users on your clipboard.
The clipboard contents will be kept around until you log out. You can use the same clipboard to assign a number of roles to a number of users in different locations. It is also possible to remove users from the clipboard in the Lookup screen, by using the remove user button (alt-r) in the user clipboard.
Select the user you want to assign a role to in user the clipboard area to in the right column of the Access tab. It is also possible to select multiple users by using the shift or control keys when making the selection.
When you are ready with the selection, select the role you want to assign to the user(s) in the drop down list at the bottom of the user clipboard. Press the assign button next to the role selection list.
You are now done assigning the role. You can repeat this step for other users on the clipboard if desired.
Users who already have roles assigned to them, possibly higher up in the site, will be listed in the user roles area in the middle column of the Access tab. Roles assigned in a container higher up in the site will be listed in the “roles defined above” column of the user roles area.
You can assign more roles to such users by selecting the checkbox in front of their user name. You can select multiple users if you want to assign the same role to them at once.
Then, select the role in the drop down list at the bottom of the user roles area. Press the assign role button next to the drop down list.
You are now done assigning the roles to existing users.
Again, go to the user roles area in the middle column of the Access tab.
You can only remove roles from users in the location where this role has been assigned to them. If the role has been assigned higher up it is not possible to remove the role in the lower location. If you have the right access, you can go up to the Access tab of the container using the up arrow in the tab or by using the sidebar, until you reach the point where the role is assigned.
You can revoke a role by using the checkboxes in the “roles defined here” column. After selecting the roles you want to revoke, click the revoke role button below the checkboxes in the bottom right area of the user roles area.
You are now done revoking the roles. If you revoke all roles from a particular user, the user won't be shown anymore in the user roles area.
Silva's Groups functionality comes from a separate product called Groups (surprise). Your Silva may not have Groups installed, in which case you won't see anything about Groups in the Access screen.
It could also happen that the Groups product is installed on the file system, but hasn't been activated in Silva. In that case you see a warning message in the Access screen, with instructions about what steps to take.
The Groups product is available from http://www.zope.org/Members/infrae/Groups. Its documentation is included with the Silva documentation; see the Groups screen document.
Silva has a Membership system that is turned off in a default installation. If it's activated, the following section applies.
The Membership system in Silva allows users to request roles at specific locations. If the Email Service is activated, Chief Editors are notified about a request with an email that includes a link to the Access screen (otherwise the request just appears in the Access screen at that location). Requests are listed in the “Pending requests for roles” table. To process a request:
The user will be informed by email if the Email Service is active, otherwise they will just be granted access.
The previous section has discussed how to assign roles to users
and groups of users. The roles Reader, Author, Editor, Chief
Editor or Manager are used to give people abilities in to manage
content using Silva. In contrast, the roles Viewer, Viewer + and
Viewer ++ are used to restrict access to the published areas of
the site: they are used to give people the right to view the
content managed with Silva.
Using public access restrictions it is possible to close to the general public a certain area of the site managed with Silva. Only people with a viewing role assigned to them are then allowed to log in and view these parts of the site. Restricting access can be used to put some small areas of the site (even single documents) behind a login, or alternatively to construct a large intranet area (possibly the entire site).
Just giving someone the Viewer role won't close off any area of the site. In order to make use of viewing role assignments, an area of the site needs to be restricted for users without this role. This can be done in the “Public view access restrictions” box in the Access tab.
By default, the Silva root container has no public access restrictions but is “Open to the public”; this means everybody can view the contents of the Silva root without having to log in.
Before any action has been taken to change it, the public access restriction of all other objects in the tree will also be acquired from above, just like role assignments. This means that the whole site will be public to the world.
It possible to restrict access to a Publication or Folder to people who have a certain minimum viewing role. People who don't have this role assigned to them (either directly or through group membership) won't have access to the object then. Restricting access is done by selecting the role by which the area should be restricted and clicking the set restriction button. The restriction will now be visible in the public view access restrictions area and will be acquired to underlying objects which don't set their own restrictions.
Once an access restriction is in place, it is impossible to open underlying objects to the public again, though it is possible to change an underlying object to a lighter restriction (i.e. Viewer role needed instead of Viewer +).
If after a restriction has been set it is decided to go back to acquiring the access restriction from above, thus lifting any special restrictions in this location, this can be set by clicking the acquire restriction button. This button only appears when indeed an access restriction has been set locally.
The possible restrictions are as follows:
Anonymous
This restriction is in fact the lack of all restrictions;
anyone can see this part of the tree. It is only available if
there are no restrictions higher up. In that case, pressing
the acquire restriction button will in fact have the same
effect.
Authenticated
Only allow viewing by people who can log in (and make them
log in to view). The person logged in does not necessarily
have to have any roles assigned to them anywhere. This can be
used to restrict access only to known users (those who have a
login with this Silva).
Viewer
Only allow access to people who have the viewer role or higher.
Viewer+
Only allow access to people who have the Viewer + role or higher.
Viewer++
Only allow access to people who have the Viewer ++ role or higher.
Further information:
Adding Roles and Permissions
Restricting Public Access - screenshots
© Copyright 2002-2004 Infrae.
All rights reserved. 
