Permissions and roles

Permissions are low-level things - they specify that a user can do exactly A, but not B in a given context. Permissions are used as guards on access to methods, scripts, page templates, workflow transitions and sometimes individual components on a page.

The most common permissions are 'View', 'Modify portal content', 'Access contents information' and 'List folder contents'. These (along with a few others, such as 'Manage portal') are the so-called CMF Core permissions, found in the file 'Products/CMFCore/CMFCorePermissions.py' in variables with names such as 'View' and 'ModifyPortalContent'. In general, most content types use these permissions for accessing and modifying data. You may think that a little strange at first, but you will see later how workflow is used to gain fine-grained control over these permissions.

Permissions are assigned to roles of users, not individual users. So, in folder X, anyone in the RandomRole role can Modify Portal Content. The default roles are 'Member', 'Manager' and 'Reviewer'. There are also some "automatic" roles - these are 'Owner' and 'Anonymous'. The Anonymous role is inhabited by users who are not logged in. Most portal members have the 'Member' role, but it is not guaranteed. 'Owner' only applies where the current user is the owner of a piece of content.

In the Zope Management Interface, (almost) all objects have a 'Security' tab. Here you will see a (rather large) grid of member roles assigned to permissions. Most of these will be set to 'Acquire permission settings', which means that the roles given this permission are the same as that of the parent object. Zope security settings are additive, so if you leave the acquire flag checked and select some additional roles, you will get the roles set at the parent level plus any additional roles set at this level. You can stop this acquistion of roles by unchecking the aquire flag.

In most cases, you will not modify permissions in this way, except to set site-wide defaults for permissions other than the core permissions above. One fairly common example is to restrict the 'Add portal member' permission to managers only at the root level to close your portal to public sign-up: by default it is given to the 'Anonymous' role, which means that anyone can join the site (and thus create a new portal member). However, your first point of call should always be the workflow.

You are perfectly at liberty to add new roles where this makes sense. Since members can be in more than one role simultaneously, you probably only need to worry about a subset of the permissions when it comes to assigning permissions to a new role. Use the form at the bottom fo the 'Security' tab at the portal root to add and remove roles.

Users can be assigned to roles manually using the 'acl_users' user folder at the root of your Plone instance (not the one at the Zope root). However, it is more common to assign roles to groups and then add users to groups, as described in the next section.