{"id":343,"date":"2011-05-25T18:08:05","date_gmt":"2011-05-25T18:08:05","guid":{"rendered":"http:\/\/www.myfatblog.co.uk\/?p=343"},"modified":"2011-05-25T18:11:40","modified_gmt":"2011-05-25T18:11:40","slug":"spweb-associatedmembergroup-returning-incorrect-information","status":"publish","type":"post","link":"http:\/\/www.myfatblog.co.uk\/index.php\/2011\/05\/spweb-associatedmembergroup-returning-incorrect-information\/","title":{"rendered":"SPWeb.AssociatedMemberGroup returning incorrect information."},"content":{"rendered":"

Just recently, I\u00e2\u20ac\u2122ve been working on a solution for a client that wanted to create a meetings portal for a very formal meeting process. The basic breakdown of the site is as follows, A top level Site Collection housing http:\/\/meetings.contoso.com<\/a>.<\/p>\n

This site was created with the default groups of Meetings Visitors, Members and Owners. Then for each particular committee, there was a sub-web with Unique<\/em><\/strong>  permissions, thus ensuring separation of the committees and ensuring  that access was given to the correct groups.<\/p>\n

                      \"image\"<\/a><\/p>\n

Under each subweb, Meeting workspaces are created for each of the monthly meetings and the following process is followed:-<\/p>\n

    \n
  1. Meeting organiser uploads Meeting minutes and supporting documents. <\/li>\n
  2. Workflows triggered inviting comment from the members group. <\/li>\n
  3. Members update with comments <\/li>\n
  4. Comments are approved\/rejected and the content agreed. <\/li>\n
  5. Site is locked down as Read Only for the AssociatedMembers group <\/li>\n<\/ol>\n

    As you can see from the above, steps 1-4 are fairly standard out of the box SharePoint behaviours. The problem comes in Step 5. Not because we\u00e2\u20ac\u2122re doing anything strange with security, but because we\u00e2\u20ac\u2122re not doing it through the UI. Rather the client requirements were to provide a meeting management webpart that included an option to lock the site down through some custom code once certain attributes were valid.<\/p>\n

    To verify the correct behaviour as experienced through the UI,  navigate to the \/Commitee2\/Mtg1 subweb and choose Site Actions\/Site permissions, you\u00e2\u20ac\u2122ll see the usual UI page showing you that the site is \u00e2\u20ac\u0153Inheriting it\u00e2\u20ac\u2122s permissions from it\u00e2\u20ac\u2122s parent (Committee2)<\/em><\/strong>\u00e2\u20ac\u009d and underneath this warning, you\u00e2\u20ac\u2122ll see Committee2 Owners, Members and Visitors. This is as we\u00e2\u20ac\u2122d expect.<\/p>\n

    The problem comes in the custom code for the site which breaks inheritance and then resets the permissions for each of the groups. The groups are obtained from the SPWeb object for the current site from context.<\/p>\n

    SPWeb currWeb = SPContext.Current.Web;\r\n\r\nstring<\/span> associatedMemberGroupName = currWeb.AssociatedMemberGroup;\r\nstring<\/span> associatedOwnerGroupName = currWeb.AssociatedOwnerGroup;\r\nstring<\/span> associatedVisitorGroupName = currWeb.AssociatedVisitorGroup;<\/pre>\n