Go to: SharePoint custom permission level

Customize existing permission levels

On the "website Settings" page, under "users and permissions", click "Advanced Permissions ".

1. On the toolbar, click "Settings" and then "permission level ".

2. In the permission level list, click the name of the permission level you want to customize.

3. In the permission list, select or clear the check box to add or delete permissions to or from the permission level.

4. Click Submit ".

 

The permission structure in Moss consists of website permissions, list permissions, and personal permissions.

There are 18 types of website permissions:

There are 12 types of list permissions, such:

There are three types of personal permissions:

2. Permission level

The above provides basic permissions. Different permissions constitute the permission level in Moss. Moss itself provides us with some permission levels, and we can also customize them based on our own needs.

When we customize our own permission levels, we can refer to the moss itself and modify it based on it. We edit the existing website level, which provides a copy permission level function,
We can copy a copy and modify it on this basis to define our own permission level.

3. Demonstrate Moss permissions, relationships between users and permission objects:

4. Use the SharePoint object model to control permissions

The following classes are used:

Spuser, spgroup, sproledefinition, and sproleassignment.

Sproledefinition is used to define a role (that is, the "permission level" mentioned above ).

Its important attributes include:

Name: role name
Description: Role description.
Basepermissions: Role permissions (that is, detailed permissions are specified here)
In addition, the type attribute is of the sproletype Enumeration type, and the permission enumeration is spbasepermissions.

Sproleassignment is used for permission allocation. It is relatively simple and has only three public attributes:

Member: Who will assign permissions
Parent: Assign permissions on something
Roledefinitionbindings: Permission assigned

Member is the spprincipal type and is the spuser and spgroup parent class.
Parent: implements the isecurityxxxx interface.
Roledefinitionbindings: a collection of sproledefinition.

In 2007, each item (spweb, splist, and splistitem) that can be assigned permissions has a roleassignments attribute, which is an attribute of the sproleassignmentcollection type,
Used to assign Permissions

In addition, the roledefinitions attribute is available in spweb (only available in spweb, that is, the role can only be defined on the website)

Example:

We want to assign a user a permission on the list. The permission uses a role named "XXX ".

The Code is as follows:

Sproleassignment Ra = new sproleassignment (User );

Sproledefinition RD = web. roledefinitions ["XXX"];

RA. rolddefinitionbindings. Add (RD );

List. roleassignments. Add (RA );

For example, modify the permissions of a user:

Sproleassignment Ra = List. roleassignments. getassignmentbyprincipal (User );

Sproledefinition RD = web. roledefinitions ["XXX"];

RA. rolddefinitionbindings. Add (RD );

RA. Update (); however, if the permissions of this list are inherited from the website,

The above Code does not automatically modify the inheritance, but throws an exception.

We must manually remove this inheritance relationship:

List. breakroleinheritance (true );

True in the parameter indicates re-copy the inherited permission (if you do not change it, it is the same as the website permission). If it is false, use the default permissions defined in the list template.

If you want to create a new role, you can directly create a new sproledefinition, modify its name, description, and basepermissions attributes, and then add them to Web. roledefinitions;
Alternatively, you can select an existing role to copy the new role and change it. I will not write this code.

In addition, there are some other minor changes to permissions:

In section 2003, XXX. permissions is used to obtain the permission of XXX (which can be spweb or splist), but the permissions attribute in section 2007 is also discarded.

Permissions is a very useful thing called doesuserhavepermissions to judge the current user permission,

After the permissions attribute is discarded, this method is transplanted to the spweb, splist, and other classes.

Use List. doesuserhavepermissions directly.

In addition, this method can determine not only the permissions of the current user, but also the permissions of the specified user (through spuser)

In addition, spweb, splist, and splistitem are added with the checkpermissions method to determine user permissions. If not, an exception is thrown, which is consistent with the previous XXX. permissions. Demand method.

5. Define, assign, and inherit roles

A role consists of two parts: Role Definition and role allocation.

The role definition, or permission level, is the list of permissions associated with the role. Permissions are only controllable operations on SharePoint websites. For exampleReadUsers of the role can browse the pages of the website and view projects in the list. Unlike Windows SharePoint Services 2.0, Windows SharePoint Services 3.0 never directly uses permissions to manage user permissions. All user permissions and group permissions are managed by roles. A role definition is a set of permissions bound to a specific object. Roles are defined within the scope of the website (for example,Full Control,Read,Contribute,DesignOrLimited access), And it has the same meaning in different locations on the website, but it may be different between websites in the same website set. Role definitions can also be inherited from the parent website, just like permissions.

Role assignment is the relationship between role definitions, users, groups, and ranges (for example, one user may be the reader on List 1, and the other user is the reader on List 2 ). The relationship represented by role assignment is the key to making Windows SharePoint Services Security Management Based on roles. All permissions are managed by roles. You do not directly assign permissions to users, but only assign a set of well-defined, consistent, and meaningful permissions (role definitions ). You can add or remove users and groups from a role definition by assigning roles to manage unique permissions.

Website administrators can use the "Manage Roles" page to customize default role definitions and create other custom roles. The "Manage Roles" page lists available role definitions on the website.

Role Definition inheritance

Windows SharePoint Services supports inherited role definitions, just as it supports inherited permissions, and canceling role definition inheritance also requires canceling permission inheritance.

Each SharePoint object can have its own permission set or inherit permissions from its parent container. Windows SharePoint Services does not support partial inheritance. An object inherits all permissions of its parent and has its own permissions. Permissions Can Be unique or inherited. Windows SharePoint Services does not support targeted inheritance. For example, an object can only inherit from its parent container, but not from some other objects or containers.

When a website inherits the role definition, these roles are read-only, just as they inherit the read-only permissions of the website. The user will get a link to the parent website with a unique role definition. Default settings for all new websites (including new websites with unique permissions) are defined by the role inherited from the parent website. If the permission is exclusive, the role definition can be restored to the inherited role definition, or edited as the local role definition.

According to the following prohibition rules, the role definition inheritance in the website has an impact on permission inheritance:

· The permission cannot be inherited unless it also inherits the role definition.

· You cannot create a unique role definition unless it also creates unique permissions.

· Cannot be restored to the inherited role definition, unless it also restores all unique permissions on the website. The existing permission depends on the role definition.

· It cannot be restored to an inherited permission, unless it is also restored to an inherited role definition. Website permissions are always associated with the website role definitions.