Managing rights within SharePoint is a complex subject. First, you need to understand the definition of what rights are available. There are actually 31 different types of permissions that can be assigned to a person. These include:
List Permissions
Manage Lists – Ability to create and delete lists, add or remove columns in a list, and add or remove public views of a list
Override Check Out – Allows the person to discard or check in a document which is checked out to another user. This is especially useful when a person leaves the organization without checking back in all of the documents they had opened.
Add Items – Add items to lists and add documents to document libraries.
Delete Items – Delete items from a list and documents from a document library.
View Items – View items in lists and documents in document libraries.
Approve Items – Approve a minor version of a list item or document to publish it.
Open Items – View the source of documents with server-side file handlers.
View Versions – View past versions of a list item or document
Delete Versions – Delete past versions of a list item or document
Create Alerts – Create alerts on a list or document
View Application Pages – View forms, views, and application pages. Enumerate lists.
Site Permissions
Manage Permissions – Create and change permission levels on a web site and assign permissions to users and groups.
View Web Analytics Data – View reports on Web Site Usage
Create Subsites – Create subsites such as team sites, meeting workspace sites, and document workspace sites.
Manage Web Site – Grants the ability to perform all administration tasks for the web site as well as manage content
Add and Customize Pages – Add, change, or delete HTML pages or web part pages, and edit the web site.
Apply Themes and Borders – Apply a theme or borders to the entire web site.
Apply Style Sheets – Apply a style sheet (.CSS file) to the web site.
Create Groups – Create a group of users that can be used anywhere within the site collection
Browse Directories – Enumerate files and folders in a web site using SharePoint Designer and Web DAV interfaces.
View Pages – View pages in a web site.
Enumerate Permissions – Enumerate permissions on the web site, list, folder, document, or list item.
Browse User Information – View information about users of the web site.
Manage Alerts – Manage alerts for all users of the web site.
Use Remote Interfaces – Use SOAP, Web DAV, the Client Object Model or SharePoint Designer interfaces to access the web site
Use Client Integration Features – Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.
Open – Allow users to open a web site, list, or folder in order to access items inside that container.
Edit Personal User Information – Allows a user to change his or her own user information, such as adding a picture.
Personal Permissions
Manage Personal Views – Create, change, and delete personal views of lists.
Add/Remove Personal Web Parts – Add or remove personal web parts on a web part page.
Update Personal Web Parts – Update web parts to display personalized information.
Obviously, you would not want to manage these 31 permissions individually for every user who needs to use SharePoint. Therefore, SharePoint provides a way to group common sets of permissions into what they refer to as permission levels. SharePoint creates some default permission levels, but your SharePoint administrator can easily create others. The SharePoint administrator can also go into the definition of even the default permission levels to customize the permissions included in each level. Currently our SharePoint has the following permission levels:
- Full Control
- Design
- Manage Hierarchy
- Approve
- Contribute
- Read
- Restricted Read
- Limited Access
- Site Administrator
- View Only
- SubSite Administrator
Each of these permission levels has it unique set of active permissions. To simplify managing these permission levels, we have defined each one the same in our Internet, intranet, and collaboration site collections.
With these permission levels defined, we can group all employees into one or more of these levels (yes you can apply more than one permission level to an individual). Using permission levels makes it easier to assign the 31 permissions to an individual. It also makes it easier to make global changes to groups of people by just changing the permission settings in the permission level rather than having to change the permissions assigned to every individual.
While we can assign permission levels to individuals, we also found it convenient to group individuals together into groups and then assign a permission level to that group. For example, we can place all individuals in a department in a single group representing that department and then assign contribute rights to the group rather than having to assign a permission level to each individual in the department.
We can define groups for individual in two ways. The first way is to create the group within SharePoint. The advantage of this method is that everyone with Manage Permission rights can add and remove people from this group. The second way is to create the group within Active Directory and then associate that group with a permission level either directly as if the Active Directory group was an individual or you can add the Active Directory group inside a SharePoint group which in turn is assigned a permission level.
After you have defined the Permission levels and decided how to add users to SharePoint (either as individuals or as members of a SharePoint or Active Directory group) it is time to associate those rights with objects within SharePoint. Objects in SharePoint begin with the entire farm at the top level and move through Site Collections, and sites. Sites are further composed of lists, libraries, discussion boards, surveys, blogs, meeting and document workspaces, and more.
But it does not stop there. Lists consist of one or more items. Within a library you can have folders with unique rights and even define rights for individual documents within the folders. With thousands and sites and millions of documents, you can see how assigning and maintaining granular rights at the document level could soon become an impossible tasks.
If your head is spinning with these permissions inside of levels, assigned to individuals or groups and then applied to site collections, sites, lists, libraries, items, folders, or documents, don’t worry, you are not alone. SharePoint permissions were designed to be granular, but that does not mean that you should always take your permissions down to the deepest level of granularity. In fact, that level of granularity should be used as the rare exceptions, not the norm.
You should always define your permissions at the highest level possible with the most restrictive permissions for that group or person first. It is easier to give a person more rights as you navigate down through the physical site hierarchy to a more granular level. To remove rights, you have to break inheritance (a topic for a future time) to take away their rights and either start over or at least modify who has rights from that point through the rest of the hierarchy.
For example, we generally define user groups at the site collection level or the site level depending on the type of site. Since we modeled our site hierarchy after the organization chart, our site collections correspond to divisions and the subsites within a site collection represent departments. At the school level, the hierarchy follows similar logic with each area having its own site collection and each school within each area being a site. This does not mean that you cannot have sites within departments or within schools, but it provides us with a starting architecture.
Paralleling the site hierarchy, we also created groups based on departments and schools. That way, we could easily assign a department group to the department site and school groups to the appropriate school site. When someone is hired or transfers, we merely add them to the appropriate group to grant them rights to their new department or school site pages.
Does this solve all of our rights problems? Unfortunately no. We still have to manually maintain membership in the site owner groups since we currently have no way to determine who the owner of individual sites should be. Similarly, we manually manage the Approver groups based on requests by one of the site owners since approvers ultimately control what information SharePoint surfaces to site visitors. Therefore, while anyone who is a member of a department could potentially add, edit, or delete content from a department site, the approver group members have final say in what gets published.
For collaboration sites, we define two major wildcards to categories the content and purpose of these sites. The first, team sites, generally provide a collaboration area for members of a department or a subgroup within a department where they can store documents and collaborate. Many team sites restrict access to only their team members unlike a department intranet site which is viewable to all employees. The second collaboration site type is a project site. These sites often include members from more than one department and even more than one division. Project collaboration sites are also generally short lived and should be archived and deleted after the completion of the project.
With only a few exceptions, we do not encourage the use of special permissions within a library such as at the folder level much less at the item or document level of lists and libraries. Managing permissions at this granular level gets very complex and can result in a lot of lost time trying to determine why a person has or does not have permission to a specific item or document. If permissions for some documents are unique compared to other documents, we strongly recommend that they be placed in a separate library so that the permissions can be appropriately defined for the entire library rather than individual folders or files.
In the near future we will be empowering individual site owners for the Internet, intranet, and collaboration sites with the ability to manage the permissions within their own site. I will let you know how this effort goes at that time.
SharePointMike's Blog 