Collaboration: Using the Sharing Tab

« Return to page index

This tutorial explains many common use cases for collaborating within Plone. You will find examples of the many ways you can control content editing and adding by users.

Letting others add content to a folder you created

Let's say you want to grant the ability to add new content to a user, but not allow them to edit other content that they did not create themselves.

In this example, Jane Smythe has full access to her Plone site. She can add, edit, delete and publish content anywhere in the site. For now, she has created a folder called "Documentation" and added one Page to it, "Project Overview". She hasn't published either the folder or the document. The default workflow for this Plone site has not been modified.

Now she wants to let her colleague, George Shrubb, add content to the Documentation folder. He have permission to edit any of the existing content, but she needs him to start adding content. Before we follow along with Jane, let's take a peek at what George currently sees when he logs in on this Plone site:

 

Notice that as of right now, George can't even view the Documentation folder, because Jane created it and it is still in the Private state. All the default permissions are currently in place and work as expected.

Jane gives George the permissions he needs to add content to the Documentation folder.

Jane navigates to the Documentation folder and clicks on the Sharing tab:

One of the first things to notice is that Jane already has all the permissions available for this Folder. These permissions were actually granted from higher up in the site as indicated by the green/check mark symbol.

In this example, Jane will grant George "Can add" permission on the "Documentation" folder so that he can add content to the folder. First, she searches to find him by his name:

Jane can now add specific permissions for George in the "Documentation" folder. She is going to give him the "Can add" permission and then click on "Save":

 And that's all there is to it! Let's see how George views the site now.

Note: George does NOT need to log out and log back in. Permissions are always current because they are checked every time a user accesses anything (e.g. clicks on a link) on a Plone site.

George clicks on the Home tab (for example) to refresh his view of the site and can now see the "Documentation" folder:

When George clicks on the "Documentation" tab, he notices that he can view all the content in the "Documentation" folder, and he now is able to add the available content types to the folder, as shown in the Add new... menu:

George wants to review what Jane has already created, so he clicks on the Project Overview link and sees:



While George can view the document, his limited permissions do not allow him to edit it or change its state. The only thing he can do beyond viewing the document is to make his own copy of it.

George adds a Page called "Widget Installation" and creates the content for that Page. When he's done he saves it:

 

Jane views the work George has done. She clicks on the "Documentation" tab and sees that George indeed has been busy. She clicks on "Widget Installation" page to take a closer look:

Notice that Jane has full access to the page that George created. She can edit it as well as cut/copy/paste it. Instead, she will wait until George submits the page for review before actually doing anything further with this page.

Letting others edit content you created

Let's say you want to grant the ability to edit certain content to particular users, but not allow them to publish it.

Both Jane and George have been hard at work creating pages in the Documentation folder. Jane has published the Documentation folder and several pages:

Jane has decided that she wants to turn over all editing (but not publishing) control of the "Documentation" folder to George. So she returns to the "Documentation" folder and clicks on the Sharing tab:

sharing10.png

From here she only needs to tick the "Can edit" check box and George will be able to edit all the content in the "Documentation" folder -- including the "Documentation" folder itself. When George next visits the folder and clicks on "Project Overview" (which is a Page that Jane created), this is what he sees:

sharing11.png

So now George can edit any item in the "Documentation" folder regardless of who created it or when.

Meanwhile, Molly has joined George as a new team member. George helps Molly start updating the "Widget Installation" document. He goes to the sharing tab for "Widget Installation" and searches on Molly's Full Name (not username) and gives her the "Can edit" permissions on this document.

sharing12.png

Now when Molly goes to the "Documentation" folder, she can see the two published items and the private item that she is now allowed to edit:

sharing13.png

And, in fact, when she clicks on the "Widget Installation" document, she is able to edit it:

sharing13b.png

Notice, however, when she clicks on either of the two items she isn't allowed to edit, she doesn't have any additional access. She can view these two items because they are published and in the default Plone workflow (meaning that anyone can view them).

sharing13c.png

One final note on this example: if the "Documentation" folder was not in the published state OR Molly had not been given any other permissions (for example, "Can view" on the Documentation folder), then Molly would have needed the complete URL to reach the document she had been given access to edit. Permissions are very specific in Plone!


Creating a Simple Intranet

Let's say you want to have a private section (folder) within your site for a group of user to go in and edit and add content freely, but restrict this group from editing content elsewhere on your site.

Suppose your organization is made up of staff, volunteers, and board members. Your staff are obviously responsible for creating and maintaining content on the website. Therefore, they need to have the highest level of access to be able to do that job. However, board members and volunteers may want to manage their own private content, or have access to sensitive information that you do not want publicly available.

The best solution is to create a space on your website specifically for these groups to "own" and manage for their own needs. Usually that takes the form of a private folder or page.

Background

Before we begin this tutorial, you should familiarize yourself with the concept of users and roles in Plone. This is useful information you should know about before reading this tutorial.

The steps involved

  1. Create users and set their global role
  2. Create a group and add users to that group
  3. Create the Intranet folder and grant edit, add, and view permissions to the group


Create Users

If you haven't already done so, you need to create the users on your website who will use the private Board folder. To see what users have been created for your site, go to Site Setup -> Users and Groups Administration. From here you can Add New User or Show All to see a list of everyone. show-all-users.gif

Each user has a User Name, Email Address and Role column. This is where you set the Global Role for a user. Global Role controls how that user can behave across the entire site. For your Intranet members, you should leave them in the member Role. For your site managers, you can give them the manager Role. When you're done adding new members and setting their roles, you're ready to move onto the next step.

Create a Group and Add Users

Now that you have created your list of Intranet members, it's time to create a group for them. The purpose of creating groups is that groups can be given both Global and Local roles, which means you do not have to change roles for each individual. The idea is to create one group which gets assigned a role for a folder. Any users in that group inherit the local role.

From Site Setup -> Users and Groups Administration click on the green groups tab in the task bar. You should see the title Groups Overview and any existing groups listed there (many sites have Administrators and Reviewers as default groups). Click the Add New Group icon and fill out the fields.

You should now see your Intranet group in a listing that looks like this:

permission-groups.gif

 

Assign your new group's global role as Member, to prevent all Intranet members from having full access to all parts of your site.

In order to help your Intranet users manage their content, you should create a Recent Items Portlet for them. You can do this via the Group Portlets tab accessible by clicking on the name of the group.

At this point the group has been created as well as your list of users. Now you must add users to your group. To do that, click on the group name. From there you can search for individual members, or click the Show All button to see everyone. Select users one at a time, or use the checkbox at the top to select all users. Then click the add selected groups and users to this group button to finish.

 

Create a Folder and Set the Sharing Permissions

If you haven't already done so, at this point you should create a folder for your Intranet. Be sure the Publishing State for the folder and its contents are Private. If you do not, anonymous site visitors can potentially find and access your restricted documents.

Once that is done, you are ready to assign Permissions on that folder for your Intranet group. To do that navigate to your Intranet folder and click on the green Sharing tab. Use the search within the Sharing screen to find the Intranet group. The group name will appear in the sharing listing. You can now assign the permissions for this folder.

intranet-folder-permissions.gif

As you can see there are four options for permissions: Can add, Can edit, Can view, and Can review. The typical permissions for an Intranet folder are: Can add, Can edit, and Can view. You can of course implement a submit-and-review process or create two or more groups with varying levels of local permissions within the Intranet folder (for example, one group who can add only, and one that can edit only).

Note: the "Logged-in users" group is a 'virtual group' which you can use to restrict local permissions for any logged in user, regardless of their global role.