- features that create workflows requiring specific groups for approvers
- features that create custom libraries or list which only specific users(groups) should be able to access
- features with custom application pages that provide specific functionality based on group membership
The list goes on and on; and while you could let the site owners create these groups and assign the necessary permissions (for most of these scenarios); wouldn’t it be safer if this was done by you. Think of all the time you’ll save on calls where you would otherwise have to explain how to do this, or troubleshooting where they’ve gone wrong. True, they’ll still have to add the users to the groups; but if they cant even do that maybe their place shouldn’t be anywhere near SharePoint.
In this posting I hope to demonstrate just how to do this by developing a feature that creates a Custom Group when activated.
We’ll begin by creating a folder called “CustomGroup” in the SharePoint feature directory (ie. “c:\program files\common files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATUES\CustomGroup”)
Next we’ll create the FEATURE.xml file, it should look as follows:
Description="This Feature Creates a Custom Group"
Notice the ResourceAssembly and ReceiverClass attributes. These serve as references to the assembly that will handle the FeatureActivated, FeatureDeactivating, FeatureInstalled and FeatureUninstalling events. The PublicKeyToken of the ReceiverAssembly attribute has been set to TBD, we wont have this until we’ve created and compiled the class.
Next we’ll create the SPFeatureReceiver class referenced above. Your code should look as follows:
class FeatureReceiver : SPFeatureReceiver
public override void FeatureActivated(SPFeatureReceiverProperties properties)
//get a reference to the site collection where the feature is activated
using (SPSite site = properties.Feature.Parent as SPSite)
//get a reference to the root site / web of the site collection
using (SPWeb web = site.RootWeb)
//get a reference to a Site Owner
//(there should always be at least 1; position 0 of the
//we'll make this user the owner of the custom group
SPMember siteOwner = web.SiteAdministrators;
//prepare the group name
string grpName = "Custom Group";
//check if group exists
bool grpExists = false;
//THIS CODE SHOULD BE MOVED TO ITS OWN HELPER FUNCTION
//OR UTILITIES CLASS. IN FACT MOST OF THIS CODE NEEDS
//TO BE REFACTORED
foreach (SPGroup group in web.SiteGroups)
if (group.Name.ToLower() == grpName.ToLower())
grpExists = true;
//add the custom group to the site
//if it doesnt allready exist
web.SiteGroups.Add(grpName, siteOwner, null,
"Custom Group that I created because I can!");
//get a reference to the group we just created
SPGroup customGroup = web.SiteGroups[grpName];
//add the group to the quicklaunch
web.Properties["vti_associategroups"] + ";"
//.....FeatureDeactivating, FeatureInstalled, and FeatureUninstalling methods
The code has enough comments to be self explanatory. Make sure you create your class under the right namespace, as this is referenced in the FEATURE.xml file. You’ll also need to sign the assembly (give it a strong name), go to http://msdn2.microsoft.com/en-us/library/ms247123(VS.80).aspx for step-by-step instructions on how to do this.
Compile the assembly and add it to the GAC. While in the GAC,right click the assembly, select properties and make a note of the Public Key Token. You’ll need to update it on the FEATURE.xml file.
Deploy your feature via the Installfeature command in STSADM or by packaging it and deploying it in a WSP file.
Since we’ve set the scope of the feature to “Site”; you’ll have to activate your feature from the “Site Collection Features” link on the Site Settings page. If you are on a sub-site/web you’ll need to click on the “Go to top level site settings” link first.