October 2006 - Posts

• SharePoint 2007 SiteGroups - part 2 - Creating SiteGroups in code

  This is the second article in a series (of 3) about SharePoint sitegroups. In part 1 I discussed how you can manage these site groups by using the MOSS interface. I also introduced the scenario that we will build on in this item. After creating a special teamsite for each of our customers, we configured the site groups for this customer site. This was quite a few mouse clicks. Takes a lot of time to configure this manually. Also we want to standardize the naming of these groups across all sites that have the same site definition. That is hard to do manually. And we prefer to give our account managers a self-service system to create and maintain their customer sites. Explaining them how to configure sitegroups and permission levels is not going to work. We created a workflow that does all this work for us. This workflow is triggered by editting or creating an item in a list with customer data. This workflow is part of what we call our “SiteBuilder”. In this post I will show how you can create the same sitegroups and configure the QuickLaunch in the site to show them. First we’ll get a reference to the site and we will try to find the account manager:             string customerName = "Contoso";             string accountManager = @"office2007\jsmith";               SPSite site = new SPSite(string.Format("http://office2007:90/customers/{0}", customerName));             SPWeb web = site.OpenWeb();             SPUser owner = web.AllUsers[accountManager]; Then we generate the name for the Customer Team group. In this case this will be “Contoso Customer Team”. We will check if the group already exists. If it doesn’t, we’ll add it. The Account Manager will be the owner of the group. Update 21-01-2007: Please read this item if you want to set a hyperlink in the group description, just like SharePoint does out of the box.             string groupName = string.Empty;             SPGroup group = null;             string groupAssociations = string.Empty;               groupName = string.Format("{0} Customer Team", customerName);             group = GetSiteGroup(web, groupName);             if (group == null)             {                 web.SiteGroups.Add(                     groupName, owner, null,                     string.Format("{0} customer team", customerName));                 group = GetSiteGroup(web, groupName);             } The owner is the second parameter of the Add. This is a SPMember object, so it can be both a user and a site group. Being the owner of the groups, the Account Manager can manage the membership of these group. He can grant people access to his site, by adding them to the groups, depending on their role. They therefore do not have the “Manage Permissions” permission on their sites, but they can manage the membership themselves. And we keep the nice clean, clear, standardized security setup for all our customer sites. The function GetSiteGroup that you saw above is just a helper function to test if a group exists.         private SPGroup GetSiteGroup(SPWeb web, string name)         {             foreach (SPGroup group in web.SiteGroups)                 if (group.Name.ToLower() == name.ToLower())                     return group;             return null;         } If you get it straight from the collection, you get an error when it doesn’t exists. The next step is to setup the SiteGroup we just created as the “Visitors” sitegroup for our site. By doing this you will see this group appearing as “Visitors to this Site” when you go to “Set Up Groups”. It took somedigging around before I found where this is stored. It turned out to be the property bag of the SPWeb. If you are interested in the property bag, please check this weblog by Serge van den Oever. The property bag has 3 properties for these groups: vti_associatevisitorgroup vti_associatemembergroup vti_associateownergroup To set one of the values, use this line of code:         web.Properties["vti_associatevisitorgroup"] = group.ID.ToString(); For the other 2 groups the process is exactly the same. For the Account Managers group we will make 1 difference. We will already add our account manager to the group, which gives him/her direct access to the site after it is created. This can be done when creating the group by using the defaultUser parameter (an SPUser object):         web.SiteGroups.Add(               groupName, owner, owner,               string.Format("e-office account managers team for {0}", customerName)); The last step is to configure the site to show our 3 custom groups in the quick launch when users navigate to “People and Groups”. Once again this is stored in the propertybag. This has a property called “vti_associategroups”. This contains a string value with the ID’s of the groups that you want to show, separate by “;”.         web.Properties["vti_associategroups"] = "23;24;25";         web.Properties.Update(); Please don’t forget to call the Update of the property bag after you updated any of these properties, otherwise they will not be persisted. If all is well you end up with 3 new sitegroups, that are attached to the site, accessible from the People and Groups menu and can be managed by the account manager: I have only shown the most important pieces of the code here. This should be enough to get you started. Next time I will show how to set the permissions for these groups.   Posted Oct 18 2006, 02:10 PM by tonstegeman with 2 comment(s)

• SharePoint 2007 SiteGroups - part 1 - the basics

  This post is the first in a small series. This will be about SharePoint sitegroups in MOSS 2007. It is based on the usage of sitegroups in the “Collaboration Portal” site template. This is the site template that you typically use as a starting point for an intranet. If will first describe how these groups and their permissions are set up. After that I will describe a scenario where we have customer team sites, and their security setup. When you create a new site collection, the top level site automatically gets a number of new sitegroups. You can see these groups, if you go to your top level site, select Site Actions and then click People and Groups. This screen shows all available sitegroups and their members. The most important ones for our site are: <site_name> Visitors <site_name> Members <site_name> Owners These 3 groups are actually tied to the site itself. This connection can be seen when you are in People and Groups and you click the Set Up Groups menu item from the Settings menu. As stated in the comments, the Visitors group has “Read” permissions. This means that this SiteGroup has been assigned the “Read” permission level. Members has “Contribute” and Owners has the “Full Control” permission level. These Permission Levels are new in MOSS 2007. Basically they are a set of permissions grouped together. “Read” for example is a set of 11 permissions (like View Items, Open Items, Create alerts, etc.). If you want to know more about permissions and permission levels, you should check this post by my coworker Henk Hooiveld (yes, we still work on the same project). The fact that you see these groups here does not actually mean that they have the permissions that are described in the comments. This is configured in the site’s permissions. Click on “Site Permissions” in the Groups Quick Launch, or click Site Actions – Site Settings – Modify All Site Settings – Advanced permissions. Here you see our 3 site groups and the permission levels that they are assigned. These permissions are inherited to all subsites. On any of these subsites you can setup the 3 groups and connect them to the site. In my scenario we have a site called “Customers”. This site is a parent site for all our customer sites. Each customer site is a teamsite. We setup our permissions using the same model. We also have 3 usergroups that we want to add: <customer name> Customer Team (these are our customers who have read access to the site) <customer name> Customer Support Team (our internal support team for this customer; contribute access to the site) <customer name> Account Managers (they have full control over their site)  In our customer site, go to People and Groups and click Set Up Groups from the Settings menu. Here you can directly create 3 new sitegroups by clicking the “Create a new group” radiobuttons. In the same screen you can directly add members to these groups. You don’t need to add members, except for the Owners group. This group has to have at least 1 member. If you select Create a new group, the group will by default be named “<sitename> Visitors”. If you read the warning at the top of the screenshot above, you will see what we just have seen. The fact that we now have configured the 3 groups for our site, does not mean that we have set the permissions. We should do this by adding these groups to the parent site (as is suggested) or by breaking the permission inheritance and create unique permissions for our site. The last option is what we want. If we don’t do anything, our groups are created, but adding people does not help, because permissions are not set.We do this by clicking Site Permissions. In the Actions menu we select Edit Permission. SharePoint asks us if we are sure and we end up with unique permissions for our site. By doing so the parent permissions are copied to our site. We delete all our existing permissions and add our custom groups that we have just created. Deleting can be done by selecting all items and selecting “Remove User Permissions” from the Actions menu. By clicking Add Users in the New menu, we can add our groups. (it is called Add users, but you can also add groups). Select the group and select “Give users permission directly”. Select the appropriate permission level and click OK. After configuring our 3 sitegroups we end up having this permission setup: This is a little off topic, but because we now have unique permissions on our sub site, we can also setup unique permission levels in our site. In the screenshot above you see we now have a Settings menu in the Site Permissions screen. If you select the option Permission Levels, you can create unique permission levels for your site. Nice option, but think about it carefully if you really want this. Things can get very complicated by using unique permission levels. The last bit that I wanted to show is how you can configure you site to display just the 3 custom groups in the quick launch when you go to People and Groups in the customer site. This makes it much easier for our account managers to manage the permissions by adding people to the groups. Otherwise they would have to scroll through all site groups to find their specific groups. Although we created the site groups directly from our site, they are created in the top level site. In People and Groups in the customer site, open the Setting smenu and select “Edit Group Quick Launch”. This gives you a box where you can select our 3 custom groups. The rest will be available through the “More” link. After selecting the correct groups, this looks like this: (instead of showing all groups, with the 3 most important for this site somewhere in the list) As we have seen in this post, SharePoint offers a nice way to setup a security model (using permission levels and sitegroups) and make it easy to manage the membership of these groups easily from the site that uses them. Configuring this however is a lot of work, especially when you want to do this for a lot of sites in the same way. In the next post I will describe how you can create these sitegroups from code. Posted Oct 14 2006, 02:10 PM by tonstegeman with 4 comment(s)