Implement Roles-Based Logic in InfoPath Forms

At this point, ensure that you have full control over the list and everyone else has read access to the list. It will look similar to the following:

The above figure depicts a scenario where Home Owners has restricted read access to the list (so that they can access the list in the first place). An account, “accountspayablemgr” has access to the list in read mode (so that that role can also view version history). The administrator account has full control and can manage security for individual items in the list.

Repeat this process for the two items in the list themselves. To do this, hover over the title and select “Manage Permissions”. Give read access to the appropriate items for the appropriate user ID’s. Using figures three and four as an example, the account “administrator” is afforded read access to the item “Admin” and the account “accountspayablemgr” is provided read access to the “Approvers” list item.

Create a Test Harness InfoPath Form

Create a simple InfoPath form with the following characteristics:

• Two Boolean fields named “isMemberAdmin” and “isMemberApprovers”

• A data source that reads from the custom list created above.

Your form should look similar to the following when complete:

Finally, add a rule that executes when the form is opened. Do this via:

• Tools

• Form Options

• Open and Save

• Rules

This is the heart of the solution, so pay close attention to these steps. We’re going to add a new rule that has two actions. The first action simply reads from the custom list.

The second action is more interesting. We assign a value to the “isMemberAdmin” field by checking to see if the string-length of “Title” on the custom list is greater than zero. The trick is to filter our lookup on Title where Title = “Admin”. The following series of screen shots walks you through a click-happy Infopath client:

The figure 6 shows:

• Adding the new rule

• Adding an action, “Set a field’s value” for the “isMemberAdmin” field

From here, click “Insert Field or Group”, select the Roles list (or whatever you named your data source) and you should see something like this:

Click Filter Data … and filter the lookup where Title = “Admin” as shown :

Last, but not least, wrap that filter inside a string-length function. Click OK and test. You’re successful when you see something like the following upon opening your form:

To obtain the above results, I logged in as an administrator (as per the role, not to be confused with a farm or site administrator). The InfoPath form correctly determined that I am a member of the “Admin” group, updated the “isMemberAdmin” Boolean field and displayed that on the form.

Now that the logic is complete, it’s a simple matter to use the “isMemberAdmin” to hide or disable buttons, sections or generally use this fact anywhere you want in your form.

Summary

This tip shows how we can leverage SharePoint’s item level permission functionality to implement a roles-based security model in our InfoPath forms. This technique has several advantages:

• It always works, even in a forms based authentication environment where the username() function does not work (always returning a blank value, to be specific)

• No active directory integration. In point of fact, this could be viewed as a disadvantage, but let’s think positively. This approach allows business users to define role membership and all they need to do that is appropriate access to one custom list in the site. It affords a granular level of control and frees up IT people so that they focus on bigger and better problems.