This recipe shows you how to work out the permission levels you have been granted in a SharePoint Team Site.
This recipe works for:
SharePoint 2010 Foundation
SharePoint 2010 Standard Edition
SharePoint 2010 Enterprise Edition
SharePoint 2010 Online (Office 365 Edition)
You do not require any particular permission level to use this recipe. However, the outcome of this recipe is directly determined by the permission levels that you have been granted.
You will only be able to follow this recipe as far as your permission levels will allow. If you have not been granted any access to the site, an error message will be displayed when you attempt to access it. Once you are unable to proceed, the recipe is complete. Check the How it works section for a detailed explanation of the permission levels that you have.
Open Internet Explorer and navigate to the SharePoint Team Site that you want to check your permissions in.
If the Team Site is displayed, then you have been granted Read permission level or higher (an Access Denied error means you have not been granted any access to the site).
Access the Page ribbon on the home page. Confirm that you can see the Edit icon.
Access any document library (for example, Shared documents), confirm that you can you can see the Add document link.
Access the Site Actions menu. The options displayed should match those in the following screenshot. If all these options are present, then you have been granted the Full Control permission level to the site. If the Site Permissions and New Site options are missing, then you only have the Design permission level.
Everything that you can or can't do in SharePoint is determined by the permissions that you have been granted. SharePoint doesn't tell you the permissions that you have, it only stops you doing or seeing the things that require permissions that you do not have. SharePoint employs a "security trimmed user interface". This means that SharePoint doesn't let you see or do the things you don't have permissions for. It only shows you the content, menus, and commands that you are allowed to access.
Unfortunately, as a user, there is no built-in way to determine your permission levels. This recipe uses a systematic approach to work out the permission levels by testing for the functionality that is granted at each level. If we find the functionality we expect, then we can infer that you have been granted that permission level. As permission levels build up in a hierarchy, we start from the lowest level (that is, no access) and work upwards until we find all the permissions levels that apply to you.
Individual SharePoint permissions are collected together into permission levels. A SharePoint Team Site creates six permission levels by default: Limited Access, View Only, Read, Contribute, Design, and Full Control. You may have been allocated one or more permission levels in the site. The total permissions you have are the sum of all the permissions from the permission levels that you have been allocated.
If you receive an Access Denied message when you try to open the site, then you have not been granted any permission levels at all.
The limited a ccess permission does not give any direct access to the site. It is designed to be combined with the fine-grained permissions to give access to just particular items within a site (for example, it is possible that you would have access to just a single document library in a site but nothing else). You will not normally encounter this except in highly customized sites.
If you can see the Team Site in your browser, then you have at least View Only or Read permissions level. For all practical purposes, these permissions levels are identical so we do not try to differentiate them any further in this recipe.
If you have the ability to change things in the Team Site (for example, edit pages or upload documents) then you have been granted at least the Contribute permission level, that is, you have the ability to contribute things to the site.
If you have access to the advanced commands located on the Site Actions menu, then you have been granted Design or Full Control permission level in the site. You will probably encounter the Full Control permission level in Team Sites that you are responsible for administering or within your My Site. Full Control means that you can access all the power of SharePoint within the bounds of the current collection of sites that you are working in. You will have the ability to create new sites, add users, set permission levels, and do all sorts of wonderful stuff. However, with power comes responsibility—there is also the potential to mess things up when you have full control! Don't worry, there are plenty of recipes in this book that will help you and make sure that doesn't happen.
SharePoint provides the ability to create many different types of site, such as, Team Sites, My Sites, Document Workspaces, and Publishing Sites. Some of these sites introduce extra permission levels such as Manage Hierarchy or Approve. The same principles used to determine the permission levels in a Team Site can be applied to the other sites.
SharePoint permissions levels can be directly assigned to individual SharePoint users. However, administrators do not usually do this as it quickly becomes very complex and difficult to manage. Instead, SharePoint sites can contain groups. These groups are used to hold collections of users who all require the same permissions levels (that is, need to be able to play the same roles) in the site. Multiple permission levels are assigned to the SharePoint groups, and then the users, who require those permissions levels, are added to the group.
SharePoint has a hierarchy of securable objects that is things that can be secured by permissions in SharePoint. Normally, permission levels are inherited from their parent objects (as this keeps things simple and easy to manage). Site collections define the security to be applied and these settings are inherited down through all the sub sites, pages, document libraries, lists, documents, and list items that they contain.
However, this inheritance can be broken and permission levels can then be applied at any level in the hierarchy. We might want to do this in a number of scenarios—for example, to create a document library that contains sensitive document that only selected employees are allowed to see. If you encounter odd permissions or access errors within a SharePoint site, consider that the site administrator may have chosen to break the security inheritance and applied unique permissions to the item you are trying to access.
Checking another user's permissions in a SharePoint site
Applying unique permissions to a SharePoint list
Adding users to a Team Site, Chapter 2