Roles, groups, permissions, workflows, states, transitions are all a part of Plone's robust security model. Here's an introduction to the basic Plone permissions you'll encounter on a daily basis.
Let's start off with some basic terminology. Permissions are individual rights that give the user the ability to perform an action. Roles are a combination of permissions. Both users and groups can be assigned roles.
Roles are a combination of permissions that you will assign to your users. Plone comes with a basic set of roles, each of which already has certain permissions assigned. Below you will learn a little bit about the defaults for each role.
Most of your site users have the "Member" role. By default, a Member can see anything that is published, see the contents of a folder, see a list of other portal members and groups, and see portlets. Depending on how your site is customized, Members may not have access to certain portlets or specific parts of the site. I keep track of what a Member has access to by reminding myself that a Member cannot change content and can only see what has been published. You will want to assign the Member role to your every day, normal users who will not be changing content. Everyone who joins your site should be assigned this role.
The Reader role is the opposite of the Member role. Readers can view content items that are in the private state, but cannot make any changes. You should assign people the Reader role when you want them to review a piece of content that is not yet published. The Reader role is great for when you want only certain people to see a piece of content. You can also use the Reader role as part of a document review cycle for users who would like to review your document but not make changes to the document.
A user with a Contributor role can do all the things a member can, plus add content, use version control, and view content that is not in the published state. A contributor cannot modify (edit) another user's content. The Contributor role should be given to users who will create content but not edit another person's content.
The owner role is inherited when a user adds a piece of content. You have to have another role, like Contributor, that has the ability to add content. Once you add a piece of content, you are automatically assigned the Owner role over this content. When you are the Owner of a piece of content, you can modify that piece of content whenever you wish, no matter what state the content is in.
A user with the Editor role by default does not have the ability to add content, but can modify (edit) content and use version control. An Editor can also manage properties of content and can submit content for publication. The Editor role should be used when a Contributor is sending a piece of content for review. The Editor will review, and change, the content and then submit it for publication.
A Reviewer role picks up where the Editor leaves off. While a Reviewer does not have as many rights as the Editor, the Reviewer can publish content that has been sent to the submit for publication state or send it back to the owner. The Reviewer also has a special portlet just for content that needs to be reviewed. Once an Editor has submitted content for publication, the Reviewer will review the content and then has the option to Publish or send back the content for the Contributor to review. The Reviewer has the final say if something gets published or not.
The Manager role is the role that can do everything. A user with the Manager role is a Site Administrator. Manager privileges are not given out lightly as this role can add, delete, and make changes to any thing in the site. While more than one person should have this role, it definitely should not be handed out to large numbers of people. Your site Manger has access to the control panel, where many site wide settings can be changed and updated. The Manager can also manage things via the ZMI (Zope Management Interface).
The easiest way to hand out permissions is to assign roles to groups. You can create a group and assign that group a role. Then, whenever you want to give someone certain permissions, you can add that user to that group. Assigning roles on a group level allows you to more easily manage large numbers of users.
There may be some situations where you don't want your group to have a specific role across the entire site. You can manage that easily too. When setting up your group in the Site Setup, do not assign it a role. Go to the folder where you want the group to have specific permissions and assign the group that role on the sharing tab for the folder. You can assign individual users permissions at this level as well. Simply add the user to the sharing tab and assign the permission to that user. When you assign roles at an object level like this, you are assigning local roles. Local roles give users (or groups) extra permissions in a very specific context. For example, you may have two groups: pirates and ninjas. The ninjas probably don't want the pirates mucking about with their content. In this case, you could create a folder for the ninjas and assign their group to have a local role of Owner over the folder. Uncheck the inherit permissions box and now your ninjas have their own folder where they can add content and the pirates cannot see or add anything to this folder. Similarly, if only the pirate captain should have access to a folder, add the pirate captain user to the sharing tab and select the correct permission. Don't forget to uncheck the inherit permissions box, otherwise your folder will inherit permissions from the rest of the site.
Now that you are familiar with the basic concept of permissions, roles, and groups, we can learn more about workflows, states, and transitions. Workflows are intricately tied to permissions and are a helpful way of managing content that multiple users must review.
Six Feet Up, Inc.
11208 Windermere Blvd.
Fishers, IN 46037 - USA
Phone: +1 (317) 861-5948
Email: info@sixfeetup.com
