Role Assignments, Role Definitions, and Inheritance
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A role 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.