The SharePoint Swiss Army Knife

Yes, I know variations of this topic have been blogged about quite a few times but I couldn’t find one that fit my particular use case and environment variables. Also, it was difficult for me to find a clear and concise guide in setting this up so hopefully this write-up will help you achieve what I’m about to show you in as few steps as necessary. But first of all, I should give props to the following blogs and links for giving me a head start and some food for thought:

http://blog.symprogress.com/2011/05/infopath-list-form-hidedisable-fields-based-on-sharepoint-group-membership/

http://www.projectpoint.at/?p=97

http://gordonduthie.net/2011/01/26/sharepoint-2010-claims-based-security-infopath-data-connections-and-getuserprofilebyname/

http://msdn.microsoft.com/en-us/library/dd946988%28office.12%29.aspx

My Scenario & Environment

Using browser enabled InfoPath 2010 forms, I have a need to hide and/or disable certain fields from users based on their SharePoint group membership. The form is used to track change requests and its status. The only noteworthy thing about my farm is that it is utilizing Claims-Based Authentication throughout.

Step 1 – Design your form

Design your browser based form as desired and then publish it to a SharePoint Form Library. Instructions on how to do that can be found here. Everything render ok? Cool, move on to Step 2.

Step 2 – Add Data Connections

Since we’d like to leverage SharePoint’s out of the box web services to figure out if the current user is in a particular group, we’ll want to add a Data Connection to https://YourSharePointSiteCollection/_vti_bin/usergroup.asmx. The method we’re interested in using is GetGroupCollectionFromUser.

Step 3 – Modify the Schema Files

I’m borrowing this step from Daniel Laksana’s blog post (Steps 3 & 4). To recap:

I. Publish > Export the source files

II. Below

<s:import namespace="http://www.w3.org/2001/XMLSchema"></s:import>

You’ll want to copy paste the following:

<s:complexType name="GetGroupCollectionFromUserType">
    <s:sequence>
      <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string"/>
      <s:element minOccurs="0" maxOccurs="1" name="Groups">
        <s:complexType>
          <s:sequence>
            <s:element maxOccurs="unbounded" name="Group" >
              <s:complexType>
                <s:attribute name="ID" type="s:unsignedShort"></s:attribute>
                <s:attribute name="Name" type="s:string"></s:attribute>
                <s:attribute name="Description" type="s:string"></s:attribute>
                <s:attribute name="OwnerID" type="s:unsignedByte"></s:attribute>
                <s:attribute name="OwnerIsUser" type="s:string"></s:attribute>
              </s:complexType>
            </s:element>
          </s:sequence>
        </s:complexType>
      </s:element>
    </s:sequence>
  </s:complexType>

III. Find this:

<s:element name="GetGroupCollectionFromUser">
   <s:complexType>
     <s:sequence>
       <s:element minOccurs="0" maxOccurs="1" name="userLoginName" type="s:string">
         </s:element>
    </s:sequence>
  </s:complexType>
</s:element>

and replace it with this:

<s:element name="GetGroupCollectionFromUser" type="tns:GetGroupCollectionFromUserType">
</s:element>

Save your changes.

Step 4 – Getting a list of the SharePoint groups that the current user belongs to

We can do this with a Form Load action. I’ve named this rule “GetUserGroups”.

Let’s now zoom into the actions that this rule will perform:

Action 1: Set the userLoginName query field with the value of the current user’s username.

Action 2: Query for data.

Step 5 – Manage rules for a field that should be disabled for certain users

In my example, we are going to disable the Request Status drop down for users that are not in the “Request Queues Owners” SharePoint group. To do so, we’ll create a rule on that field by left clicking on it and then the related rules will show up in the Rules pane. If the Rules pane is not currently open, then you’ll want to right-click on the form field and then select Rules > Manage Rules… from the drop down.

Since the data connection in our previous step brings back all of the groups that the current user is a member of, we’ll want to configure the rule to tell us if any of those groups match a predefined SharePoint group that would be able to update the field. Otherwise, the field would be disabled/read-only. Let’s configure this rule like so:

Step 6 – Publish to SharePoint & Test

We’re now ready to publish the form back out to the SharePoint Form Library and test the security trimming! If you don’t have two accounts to test with, you should be able to test with a single account by adding and removing yourself into/out of the preconfigured SharePoint group that’s being referenced within the previously configured formatting rule.

That’s all folks! Enjoy 🙂