A customer management system based on Sharepoint has strict requirements on permissions, so users have to define their own website permissions. Fortunately, the permission system provided by Sharepoint is relatively complete, the permissions we created, including the creation of SPWeb and the creation of SPListItem, were all implemented, which solved the problem smoothly. In the first phase of the project, let's talk about some of our own ideas.
Before starting, define several classes or definitions:
The Sharepoint permission system uses the concept of permission-role-object-Association, that is, for an object (such as SPWeb, SPList, SPListItem), you can add a role that already contains the role (SPRoleDefinition) (SPRoleAssignment) to change the object permissions, and the role (SPRoleDefinition) is through SPWeb in advance. roleDefinitions is added to the website. Note: Only SPWeb has this attribute to add role definitions. Other objects such as SPSite, SPList, and SPListItem cannot add role definitions. Of course, they do not need.
Related Classes:
User or user group: SPPrincipal extends two sub-classes: SPUser and SPGroup
Permission base class: SPBasePermissions, which combines custom permissions by or computing. Note: You must have the view permission before editing permissions;
Role class: SPRoleDefinition. You can use web. RoleDefinitions. Add (definition) to Add a role;
Join class: Add a SPRoleDefinition role to a SPPrincipal and add the Association to the object. Note: when the association is not added to the object, the link is invalid.
First, define your own permission system. I have defined four levels of roles. This role has the following permissions: View, create, edit, and delete. These four permissions are far lower than those of Sharepoint, here, we take creating a role as an example: At the same time, we define a role responsible for adding the Register class to the website. Each role corresponds to a Register class, so as to facilitate permission expansion and adopt Dependency inversion.
Assign permissions to objects: The SPListItem parameter can also be SPWeb or SPList. Permission assignment is generally implemented after an object is created, as shown in figure
SPWebTemplate template = web. Site. GetCustomWebTemplates (uint) web. Locale. LCID) [WebTemplate];
SPWeb newWeb = RootSPWeb. Webs. Add (rurl, customerName, string. Empty, (uint) 2052, template, true, false );
In this case, you should perform permission operations on the newWeb. The SPListItem operation is generally implemented in the ItemAdded event of spitemeventaggreger.
View Code
Private void RoleAssignment (SPListItem item, SPPrincipal groupOrUser, SPRoleDefinition role) {if (! Item. hasUniqueRoleAssignments) {item. breakRoleInheritance (true); // true disconnects and inherits the original permission; false disconnects and does not inherit the original permission} this. disableEventFiring (); item. web. allowUnsafeUpdates = true; SPRoleAssignment assignment = new SPRoleAssignment (groupOrUser); assignment. roleDefinitionBindings. add (role); item. roleAssignments. add (assignment); item. update (); this. enableEventFiring ();}
View Code
// Role base class: in fact, the base class provides the permission for viewing. Therefore, you do not need to extend the public abstract class BasePermissionRole {private string roleName; public virtual string RoleName {get {return roleName;} set {roleName = value ;}} private string roleDescription; public virtual string RoleDescription {get {return roleDescription ;} set {roleDescription = value ;}} public abstract SPBasePermissions ComposePermission (); protected virtual SPBasePermissions ComposeViewPermission () {// 34 basic permissions under Sharepoint spreturn basepermissions. viewListItems | SPBasePermissions. viewVersions | SPBasePermissions. viewFormPages | SPBasePermissions. viewPages | SPBasePermissions. openItems | SPBasePermissions. createAlerts | SPBasePermissions. browseUserInfo | SPBasePermissions. useRemoteAPIs | SPBasePermissions. useClientIntegration | SPBasePermissions. open;} public abstract BaseRoleRegister CreateRegister (); // Implement role registration through Dependency inversion and single piece} // create a role, ComposePermission () method of the override base class, expand the public class AddPermissionRole: BasePermissionRole {public AddPermissionRole () {this. roleName = "new"; this. roleDescription = "add a project to the list, add a document to the document library, and add a Web discussion comment";} public override string RoleName {get {return base. roleName;} set {base. roleName = value ;}} public override SPBasePermissions ComposePermission () {return base. composeViewPermission () | SPBasePermissions. addListItems;} public override BaseRoleRegister CreateRegister () {return new AddRoleRegister (this) ;}// register the base class: public class BaseRoleRegister {public BaseRoleRegister (role) {this. permission = role;} protected BasePermissionRole Permission; public virtual SPRoleDefinition ExecuteRegister (SPWeb) {foreach (SPRoleDefinition rd in web. roleDefinitions) {if (rd. name = this. permission. roleName) return rd;} SPRoleDefinition definition = new SPRoleDefinition (); definition. name = this. permission. roleName; definition. basePermissions = this. permission. composePermission (); definition. description = this. permission. roleDescription; web. roleDefinitions. breakInheritance (true, true); web. roleDefinitions. add (definition); web. update (); return web. roleDefinitions [this. permission. roleName] ;}}// new role registration class: public class ApproveRoleRegister: BaseRoleRegister {public ApproveRoleRegister (BasePermissionRole role): base (role ){}}
Re: http://www.cnblogs.com/ITBoy-lv/admin/EditPosts.aspx? Opt = 1