Weblog Ton Stegeman [MVP]

In this post I have described why we created a custom security model for workspaces. When adding members to user groups, the people editor is initially disabled. Users first need to select one of the available groups. Then they can members from that group, using the Browse button. The screenshow below shows this process.

This makes it easier for users to select members and they only can select members that have permissions to that part of the site hierarchy. In this post I will describe how I created this.

Step 1 – The Add Users page

The first thing to create is a new ASPX page, called CustomAclInv.aspx. Initially this page is a copy of the out of the box AclInv.aspx page, that can be found in the Layouts folder in the 12 hive. The first thing to change in our to this file is the registration of our custom page handler class:

<%@ Assembly Name="MyCompany.MyProject.Pages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1234567890123456"%> 
<%@ Page Language="C#" Inherits="MyCompany.MyProject.Pages.CustomAclInvPage" MasterPageFile="~/_layouts/application.master"      %> 

<wssuc:InputFormSection Title="<%$Resources:wss,aclinv_Step1Title%>"
    Description="First select a user group from one of the available groups. Then you will be able to select users from that group."
    runat="server">
    <Template_InputFormControls>
        <wssuc:InputFormControl LabelText="Select one of the available usergroups." runat="server">
            <Template_Control>
               <asp:DropDownList runat="server" ID="selectGroup"></asp:DropDownList>
            </Template_Control>
        </wssuc:InputFormControl>
        <wssuc:InputFormControl LabelText="<%$Resources:wss,aclinv_UserGroupsLabel%>" runat="server">
            <Template_Control>
                <wssawc:PeopleEditor
                            AllowEmpty="false"
                            ValidatorEnabled="true"
                            id="userPicker"
                            runat="server"
                            Enabled = "false"
                            SelectionSet="User"
                            PrincipalSource="UserInfoList"
                            />
            </Template_Control>
        </wssuc:InputFormControl>
    </Template_InputFormControls>
</wssuc:InputFormSection>

In this snippet I also made the changes to the People Editor. SelectionSet is set to ‘User’ and the PrincipalSource is changed to ‘UserInfoList’. Other changes I made to the CustomAclInv.aspx page are textual changes that are not relevant for this post. I also disabled the controls that allow users to set permissions directly. Warning: do not delete these controls, because then the postbacks of this page will result in an error.

Our custom ASPX is deployed in the LAYOUTS folder. Best practise is to deploy these custom ASPX pages to a custom sub folder in the Layouts folder. Because I am using the out of the box class to do the real work, I had to deploy it to the Layouts folder. Otherwise the redirects after clicking the OK/Cancel button will not work correctly.

Step 2 – The code behind

In the assembly we added a new class to handle the changes we made to the ASPX. This class inherits the out of the box AclInv page. Therefore you need a reference to the Microsoft.SharePoint.ApplicationPages assembly. In CreateChildControls the dropdown list is populated. We iterate through all permissions on the parent web. All SharePoint groups that at least have the ViewListItems permission and not have Full Control are added to the dropdown list.

namespace MyCompany.MyProject.Pages
{
    public class CustomAclInvPage : AclInv
    {
        protected DropDownList selectGroup;

        protected override void CreateChildControls()
        {
            base.CreateChildControls();
            selectGroup.Items.Clear();
            selectGroup.AutoPostBack = true;
            selectGroup.SelectedIndexChanged += new EventHandler(selectGroup_SelectedIndexChanged);
            selectGroup.Items.Add(new ListItem("-- Select a group --", string.Empty));
            using (SPWeb parent = SPContext.Current.Web.ParentWeb)
            {
                // Test if the parent is assigned and the parent has unique permissions.
                if (parent != null && parent.HasUniqueRoleAssignments)
                {
                    // All groups that have specific permissions set, will be added to the dropdown list.
                    foreach (SPRoleAssignment assignment in parent.RoleAssignments)
                    {
                        if (assignment.Member is SPGroup)
                        {
                            bool valid = false;
                            // Add the group to the dropdown if it has permissions to open items.
                            // Exclude Full Control groups.
                            foreach (SPRoleDefinition role in assignment.RoleDefinitionBindings)
                            {
                                if ((role.BasePermissions & SPBasePermissions.ViewListItems) == SPBasePermissions.ViewListItems &&
                                    role.BasePermissions!=SPBasePermissions.FullMask)
                                {
                                    valid = true;
                                    break;
                                }
                            }
                            if (valid)
                            {
                                selectGroup.Items.Add(new ListItem(assignment.Member.Name, assignment.Member.Name));
                            }
                        }
                    }
                }
            }
        }

        private void selectGroup_SelectedIndexChanged(object sender, EventArgs e)
        {
            if (string.IsNullOrEmpty(selectGroup.SelectedValue))
            {
                userPicker.Enabled = false;
                userPicker.SharePointGroup = string.Empty;
            }
            else
            {
                userPicker.Enabled = true;
                userPicker.SharePointGroup = selectGroup.SelectedValue;
            }
        }
    }
}

In the SelectedIndexChanged event, the userPicker  is enabled, depending on the availability of a user group. The SharePointGroup property of the people editor is set to the name of the selected user group. By doing this, the people editor changes its browse behavior. Instead of searching for new members, users can now select them from a list.

Step 3 – Changing the Add Users button

Next thing to do is to change the behavior of the ‘New’ and the ‘Add Users’ button in the toolbar of the People and Groups page.

These buttons must redirect the user to the new Add Users page that we just created. I first tried to do this by adding a new custom action to the menu and hiding the out of the box menu items. The problem was that HideCustomAction in a feature did not hide these items. I therefore decided to add a piece of javascript to the page to change the link to these pages. You can find the script below. It is a mixture of javascript and jQuery. The first bit is a jQuery selector that finds the ‘New’ link and replaces the link. The second bit does the same for the ‘Add Users’ link. I tried using a jQuery selector here also, but I did not succeed in finding ‘ie:menuitem’ elements using a selector.

This is script is added to the page by using a custom controltemplate. The script showed above, is stored in a ASCX file in the CONTROLTEMPLATES folder. A new feature registers the controltemplate for the ‘AdditionalPageHead’ control id.

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="F1701D3B-81C8-4FB4-8536-DE8AC7D93E92"
Title="Custom Menu Redirect Feature."
Description="Activates the custom Add Users page."
Version="1.0.0.0"
Scope="Site"
xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="controls.xml" />
  </ElementManifests>
</Feature>

The content of controls.xml:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Control
    Id="AdditionalPageHead"
    ControlSrc="~/_controltemplates/Custom/CustomMenuRedirects.ascx" />
</Elements>

The part of the solution is the one I am least happy with. Every page in the site collection that have the feature enabled has renders and runs this script. The only page that needs to render this script however, is the people.aspx page. If you know another solution to change these 2 links, I would love to hear from you.

Step 4 – Changing the Site Users web parts

As described in the previous part, our solution has a Participants page. This page has a number of ‘Site Users’ web parts. I created a custom web part that registers a piece of javascript in the page. This web part is also added to the page and when it runs, it does these 3 things:

• Change the Add Users link to redirect to the correct page using the groupid of the group that the user has selected in the web part properties.
• Add a link ‘Manage Users’. This basically is the same link as the out of the box ‘People and Groups’ link in teamsites.
• Add the ‘E-mail users’ link

The code below shows the code of this so called ‘FixMembersWebPart’ web part.

The can be downloaded from this zipfile. (for some reason I was not able to publish it directly)

‘JustAddMembersToGroups’ in this code snippets checks whether of not the feature for the custom ‘Add Users’ page is activated. If this feature is activated, the Site Users webpart will redirect the users to the custom page that was described above. If is is not activated, they are redirected to the out of the box aclinv.aspx page. This javascript was written before I knew about jQuery, now I probably would have written it using jQuery.

Step 5 – The e-mail users page

The custom e-mail users page that makes it easier for users to send the site members an e-mail is a copy of people.aspx, deployed to a custom folder in the Layouts folder. The changes are easy to do and therefore I just mention them:

• Stripped down toolbar menu
• All members are automatically selected when the page loads
• Textual changes

Conclusion

In this post I have described how we created the solution in the previous post. As you can see, it is pretty easy to build a custom user experience for adding users to SharePoint group. Making it easier for members to manage the membership of SharePoint groups, and making the security model for our project sites easier to understand.