Document Actions
7.1.
Administering Users
Up one level
Users, Roles, and Groups
Some of the key concepts in Plone are users, roles, and groups. Before I show you how to edit these, I'll cover in more detail exactly what these are.
Users
Each person visiting a Plone site is referred to as a user. The user may or may not be authenticated by Plone, and users who are not authenticated are called anonymous users. Users who are authenticated are logged into an existing user account. If they don't have an account, then usually they can create their own account.
Anonymous users are the lowest level of users in that they usually have the most restrictions. Once users log in, they gain the roles their accounts give them. A user is identified by a short identifier, for example, andym. By default, no users are created for you in Plone, except for the one added to Zope by the installer to give you administrator access. The name of that user is whatever you set up in the installer, usually admin.
Roles
A Plone site has a series of roles; a role is a logical categorization of users. Instead of setting every user's permissions individually, each role is assigned permissions individually. Every user can be assigned zero to many roles; for example, a user can be a member and a manager. Each role is identified by a simple name, for example: Member.
A Plone site has five predefined roles, split into two groups: assignable roles and not-assignable roles. Assignable roles are roles you can give to users so that when they log in, they have this role. Not-assignable roles are roles you don't grant specifically to a user but that occur within a Plone site. For example, you don't assign the anonymous role to a user.
The following are the not-assignable roles:
Anonymous: This is a user who hasn't logged into the site. This could be a user who has no account or one who has merely not logged in yet.
Authenticated: This role refers to any user who is logged into the site, whatever their role. By definition a user is either anonymous or authenticated; the two are mutually exclusive. Because the authenticated user doesn't provide much in the way of granularity, it isn't recommended for most applications.
The following are the assignable roles:
Owner: This is a special role given to users when they create an object. It applies to a user for that object only; the information is stored on the object. You don't normally explicitly assign someone as an owner. Plone does that for you.
Members: This the default role for a user who has joined your site. Anyone who joins using the join button in the Plone interface has this role.
Reviewer: This is a user with more permissions than a member but less than a manager. Reviewers are users who can edit or review content entered by a member; they can't change the site's configuration or alter a user account.
Manager: Managers can do almost anything to a Plone site, so you should give this role only to trusted developers and administrators. A manager can delete or edit content, remove users, alter a site's configuration, and even delete your Plone site.
Groups
Groups are a different concept from roles. Roles imply that a user has different permissions from someone with a different role, but a group is a logical categorization of users. For example, the marketing department may be one group, and the engineering department may be another group. Each user can belong to zero to many groups. Groups are optional; you don't need to use them, but the Plone team found them useful enough to integrate them.
Site developers can use the groups in anyway they choose, such as to group a department or a certain class of users. For most users using Plone for the first time, I recommend leaving groups unchanged; by default no groups are created for you.
NOTE You implement groups using Group User Folder (GRUF). The groups aren't part of Zope but are an extra tool for Plone. GRUF was developed and contributed by Ingeniweb.
Sharing Tab
When I discussed publishing documents in Chapter 3, I skipped past the Sharing tab because it's a more advanced feature you may not always want to use. The Sharing tab is an action in portal_actions, so if you don't want it to appear, go to that tool in the Zope Management Interface (ZMI) and uncheck the visible option. However, the Sharing tab is quite useful because it lets you give different local roles on an object in Plone to users or groups.
If you've got a piece of content you've added to a Plone site and you want another person to be able to edit it, then you need to give them more permissions for that one object. This is called a local role, and it allows you to give a user expanded rights on an item. If I write a document in Plone, I become the owner of that document and gain certain rights. If I wanted to collaborate on this document with my colleague Ralph, prior to publishing, then I need to give Ralph more permissions so he can edit that document. To do this, I go to the Sharing tab and give Ralph more permissions.
NOTE You can assign local roles on a folder or document basis. If you give users a local role on a folder, then they get that local role for every object in that folder.
The Sharing tab appears only in places where you have the rights to alter sharing—your folder being one such place. Click my folder, and then click sharing. Figure 9-1 shows the form for the Sharing tab. It has three main components; you can assign a user to have a local role on this object, you can assign a group to have a local role on this object, and you can see who has certain roles already.
Figure 9-1. Accessing the Sharing tab
To find a user to assign a role to, enter a search term (such as Gavin), which opens a list of users that match your search criteria; you can then click the user and select the role from the drop-down list. For example, in Figure 9-2, I'm giving Gavin the owner role on this folder.
Figure 9-2. Assigning a role to a user
In my earlier example, I wanted to assign rights to an individual user, but that can be annoying with large numbers of users...unless you've assigned them to groups. If I wanted to allow the whole marketing team to edit my document, I could do so. To get the groups available, just click View groups, which opens a list of groups for this site, and you can assign a local role to a group. In Figure 9-3 I'm giving Development the owner role on this folder.
Figure 9-3. Assigning a role to a group
Finally, in Figure 9-4, you can see which users and groups have the roles for this page and then remove them if you want. Once you've given someone else local roles on an object, you allow them to access the Sharing tab. Then nothing is stopping them from removing roles for you from the content.
Figure 9-4. Viewing and removing roles
Bika Mail 08. Yes we can!
