|
This is the last part in a small series on MOSS sitegroups. Part 1: The basics Part 2: Creating SiteGroups in code This last part is about setting the permissions for our custom created sitegroups from code. The first thing to do is to break the permission inheritance for our site.If our site (SPWeb) does not yet have unique permission, we’ll break it: if (!web.HasUniqueRoleAssignments) {
web.BreakRoleInheritance(false); } Next thing to check is if our custom Permission Level called “Account Manager” is already available. This permission level will be used to give our account managers a bit more permissions than the Contributor level, but not Full Control. Please note that these permission levels are called “Roles” in the object model. This snippet checks if our permission level is available. SPRoleDefinitionCollection roles = web.RoleDefinitions; // Try to find our custom Account Manager role. SPRoleDefinition role = null; for (int i = 0; i < roles.Count; i++) {
if (roles[ i ].Name == "Account Manager") {
role = roles[ i ]; break; } } If the “role” object remains unassigned, we’ll need to create our role. The first thing to do now is break the inheritance for the permission levels. Just as permission inheritance, the permission levels are inherited from the parentweb. The best way would be to create the permission level at the top level and not break the inheritance, but for demo purposes, I’ll show how to do this. Please not that your web needs to have unique permission to be able to break the inheritance for the roledefinitions. if (role == null) {
if (!web.HasUniqueRoleDefinitions) {
// Break the inheritance of role definitions web.RoleDefinitions.BreakInheritance(true, false); } role = new SPRoleDefinition(); role.Name = "Account Manager"; roles.Add(role); } After creating the roledefinition, we’ll set the permissions for our custom permission level. This sample just adds 3 permissions (to keep the sample short): role.BasePermissions = SPBasePermissions.ManageWeb | SPBasePermissions.ManageSubwebs | SPBasePermissions.ManageLists; role.Update(); After setting up the permission levels, we will grant our account managersgroup the correct permissions. First we’ll find out which SharePoint group is our account managers group by using the property bag of the site (see part 2). Using this group, the code sample create a new SPRoleAssignment and adds the SPRoleDefinition we just created to that. The role assignment is added to the RoleAssignments for the SPWeb: // Set permissions for Account Managers groupID = int.Parse(web.Properties["vti_associateownergroup"]); group = web.SiteGroups.GetByID(groupID); if (group != null) {
SPRoleAssignment assignment = new SPRoleAssignment(group); SPRoleDefinition role = web.RoleDefinitions["Account Manager"]; assignment.RoleDefinitionBindings.Add(role); web.RoleAssignments.Add(assignment); } After running our workflow (see part 1 for a description on the process), we have create a new site, created custom sitegroups for that site and set the permissions for that site.
By using some simple pieces of code, we have made our lives much easier. Creating and configuring sites for our customer teams now is much easier, quicker and always using the same model.
|
