Showing posts with label Permission Level. Show all posts
Showing posts with label Permission Level. Show all posts

Wednesday, 2 December 2015

How to create and edit Permission Levels in Office 365 (SharePoint Online)

Permissions allow SharePoint users to perform certain actions, such as edit items in a list or create a site. But you can’t assign individual permissions to individual users in SharePoint. Instead, you group related permissions together into a permission level. Then you assign that permission level to a SharePoint group.
Each site collection has its own set of permission levels. SharePoint comes with some default permission levels that you can use, such as Contribute and View Only. But if one of those doesn’t meet your needs, you can create a new permissions level. It’s a best practice that you don’t change the default permission levels.

Permissions Levels page

You create and make changes to permission levels on the Permissions Levels page.
To create or make changes to permission levels, you must belong to a SharePoint group that includes the permission to Manage Permissions. By default, you have this permission if you belong to the Owners group or if you are a Site Collection Administrator.

To open the Permissions Levels page

  1. On the top-level site of the site collection, click Settings Small Settings gear that took the place of Site Settings. > Site Settings.
  2. On the Site Settings page, in the Users and Permissions section, choose Site permissions.
  3. On the Permissions tab, in the Manage group, choose Permission Levels..
    Choose Permission Levels page.
You can make changes to any of the listed permissions levels, except Full Control and Limited Access.

Create a permission level

It’s simple to create a new permission level. You just provide a name and description, and then you choose which permissions to include in the permission level.

To create a permission level

  1. On the Permission Levels page, choose Add a Permission Level.
  2. On the Add a Permission Level page provide the name and the description.
  3. In the Permissionsarea, select the check boxes next to the list, site, and personal permissions that you want this permission level to include..
  4. Click Create.
After you create the permission level, assign it to a SharePoint group.

Create a permission level by copying an existing permission level

A quick way to create a new permission level is to make a copy of an existing permission level. You might want to do this when the existing permission level has permissions similar to what the new permission level will have. After you make the copy, you can add or remove the permissions you need the new permission level to have.

To copy a permission level

  1. On the Permission Levels page, click the name of the permission level that you want to copy. Be sure to click the link; do not select the checkbox next to the name. For example, Contribute, as shown in the following figure.
    Choose a permission level.
  2. On the Edit Permission Level page, choose Copy Permission Level, which is at the bottom of the page after the Personal Permissions section.
    Copy permission level button.
  3. On the Copy Permission Level page, type a name and description for the new permission level.
  4. Choose which permissions you want to add or remove, and then choose Create
After you create the permission level, assign it to a SharePoint group.

Make changes to a permission level

You can make the following changes to a permission level:
  • Update the name or description
  • Add or remove permissions
We recommend that you don’t make any changes to the default permission levels that come with SharePoint. You can’t make changes to the Full Control and Limited Access default permission levels.

To make changes to a permission level

  1. On the Permission Levels page, click the name of the permission level you want to edit. Be sure to click the link; do not select the checkbox next to the name. For example, Marketing, as shown in the following figure.
    Choose a permission level called Marketing.
  2. On Edit Permission Level page you can:
    • Change the description.
    • Add or remove permissions to the level.
  3. After you have made you changes, click Submit.
You can delete any permission level, except for Full Control and Limited Access. We don’t recommend that you delete a default permission level.
To delete a permission level, on the Permissions Levels page, select the check box next to the permission level that you want to delete, and then chose Delete Selected Permission Levels.

Best practices for permission levels

Permission levels apply to a specific site collection. This means that any changes you make to a permission level will have an effect throughout the site collection. Therefore, here are some recommendations:
  • Don’t edit default permission levels If you change a default permission level, the changes affect all the built-in SharePoint groups within the site collection. It can also cause confusion if you have two site collections that have permission levels with the same name, but each contains a different set of permissions.
  • Don’t delete default permission levels If you delete a default permission level, it will be removed from all built-in SharePoint groups that contain it within the site collection. This can cause users assigned to those groups to lose critical permissions.
  • Assign permission levels to SharePoint groups You can assign a permission level to a SharePoint user, but it’s easier if you assign permission levels to a SharePoint group. This can also help site performance.

What is Role Definition , Role Assignment and Role Definition Inheritance

A Users's role in SharePoint consists of two parts: a role definition and a role assignment.

The role definition, or permission level, is the list of rights associated with the role. A right is a uniquely controllable action within a SharePoint Web site. For example, a user with the Read role can browse pages in the Web site and view items in lists. Unlike in Windows SharePoint Services 2.0, in Windows SharePoint Services 3.0 user permissions are never managed directly using rights. All user and group permissions are managed through roles. A role definition is a collection of rights bound to a specific object. Role definitions are scoped to the Web site (for example, Full Control, Read, Contribute, Design, or Limited Access) and mean the same thing everywhere within the Web site, but their meanings can differ between sites within the same site collection. Role definitions can also be inherited from the parent Web site, just as permissions.


The role assignment is the relationship among the role definition, the users and groups, and the scope (for example, one user may be a reader on list one, while another user is a reader on list two). The relationship expressed through the role assignment is the key to making Windows SharePoint Services security management role-based. All permissions are managed through roles; you never assign rights directly to a user, but only meaningful collections of rights (role definitions) that are well defined and consistent. You manage unique permissions by adding or removing users and groups to or from role definitions through role assignments.
The Web site administrator can customize the default role definitions and create additional custom roles using the Manage Roles page, which lists the available role definitions in the site.


Role Definition Inheritance


Windows SharePoint Services supports inheriting role definitions similarly to how it supports inheriting permissions, and breaking role definition inheritance requires breaking permissions inheritance as well.
Each SharePoint object can have its own set of permissions or inherit its permissions from its parent container. Windows SharePoint Services does not support partial inheritance, where an object would inherit all the permissions of its parent and have some of its own permissions as well. Permissions are either unique or inherited. Windows SharePoint Services does not support directed inheritance. For example, an object can only inherit from its parent container, not from some other object or container.
When a Web site inherits role definitions, the roles are read-only, like the read-only permissions in an inherited Web site. The user will have a link to navigate to the parent site that holds the unique role definitions. The default setting for all new Web sites, even ones with unique permissions, is to inherit role definitions from the parent Web site. When unique, role definitions can be reverted to inherited role definitions or edited as local role definitions.
Role definition inheritance in a Web site has impact upon permissions inheritance in accordance with the following prohibitions:
Cannot inherit permissions unless it also inherits role definitions.
Cannot create unique role definitions unless it also creates unique permissions.
Cannot revert to inherited role definitions unless it also reverts all unique permissions within the Web site. The existing permissions are dependent on the role definitions.
Cannot revert to inherited permissions unless it also reverts to inherited role definitions. The permissions for a Web site are always tied to the role definitions for that Web site.