in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

Ton Stegeman [MVP] weblog

I have moved my blog to http://www.tonstegeman.com/blog. If you have a blogpost at sharepointblogs that does not display all the content on the right hand side, please go to the new blog. It has all the posts that are on this blog as well. I you have any feedback, please send me a message through the contact form.

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.

Sitegroups3

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”.

Sitegroups4

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.

Sitegroups5

After configuring our 3 sitegroups we end up having this permission setup:

Sitegroups6

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)

Sitegroups7

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.

Comments

No Comments

Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts