Thursday, May 31, 2012

InfoPath 2010 - Restricting control visibility based on permissions.


One of the common functional requirements of many InfoPath based systems is to restrict button and other control elements and associated functionality available to specific groups based on group membership. There are a number of technical approaches to this, including:

There is however a simple way based on a list external to the list the form is bound to, and setting the permissions that way. In this example, we look at a simple Save, Submit button configuration, but this approach could be expanded to many form elements on an InfoPath form.

Our requirements are:
  1. User group one can only view “Save” button.
  2. Users in group two can only view “Submit” button.

Creating the button list and setting up permissions

The first step in setting up this functionality is to create the button list. Create a list on the same site as your InfoPath form and associated list called “Buttons”, and change the column “title” to “Button Name”. Add the two buttons as items, one as “Save” and one as “Submit”.

Next, create two groups on your site, one called “CanSave” and one called “CanSubmit”. Add all users who should be able to save the form to the “CanSave” group. Add all users who should be able to submit the form to the “CanSubmit” group.

Go back to the button list you created, and edit the permissions for the two button items. The “Save” button should have the “CanSave” group associated, the “Submit” button should have the “CanSubmit” group associated.

Once complete these two steps, validate the permissions are working as expected. Log in as a user in the “CanSave” group (but not the “CanSubmit” group) and view the button list. You should only be able to see the “Save” button item in the button list. Login as a user in the “CanSubmit” group and ensure you can only see the “Submit” button.

Adding the buttons to the form and setting up rules

This step assumes you have otherwise already created a form and have it bound through its main data connection to a list or library. This step also assumes that you know how to configure both save and submit buttons otherwise for intended actions; the only functionality covered by this step is configuring the rules to show or hide buttons based on values in the external button list.

Click on the “Data” tab on your form in InfoPath, and add a new data connection to the SharePoint button list you created earlier. Go back to home tab, and add two buttons to the form. Right click on each, name one “Save”, and one “Submit”.

Open the “Rules” pane if it isn’t open already, “Manage Rules” button on office ribbon on “Home” tab. Click the “Save” button you just created, and, in the Rules pane, click “New” and select “formatting”. Name your rule “Hide Save". Click inside the “Condition” section and set up the condition as follows:
  1. In the first drop down list, select “select a field or group”.
  2. Change “Data Source” to “Buttons”.
  3. Open the “dataFields” folder, open the connection, and select “ButtonName”. “Title” will show up in the “Select” field due to SharePoint limitations around changing the title column. This is fine, click “OK.

4. Since SharePoint InfoPath rules default to show, and are only conditional on hide, we have to isolate the hide condition rather than the show condition. Select “is not equal to” in the second rule area, and then select “Type Text” from the drop down list, and type in the value that this button should NOT be equal to to hide the value, as shown in the next figure. Click “OK”.

5. Within the rules pane, check “hide this control” under the “Formatting” section:

6. Repeat this process for each of the buttons on your form.
7. Publish your form to a SharePoint site or form library.

Troubleshooting and Conclusion

Once you have published your form, you should be able to login as a member of each group and open the form. Only the buttons items you have permissions to in the associated list should show up in the form. If all buttons show up (instead of obeying permissions), ensure the permissions are correct in the associated button list, you should only be able to view the items in the button list that your associated group has permissions to:

If this checks out, then the problem is isolated to the rules in the InfoPath form, tweak and user “Preview” until it’s working. There are some complex ways of achieving this functionality through web services and other approaches, as seen in the blog post first linked to from this blog. However, it can be much simpler, faster, and easier to user SharePoint list permissions to achieve the same functionality in an easy to maintain way.


Jasim Khan said...

Excellent article!

jammy heris said...
This comment has been removed by a blog administrator.
ElisaKlahsen said...

Very Nice! Can this be applied to a section, too?

steve said...

Yes, any control that can use rules to dictate visibility can use this approach.

Pinger said...

Great article - but I have a problem.

I used this to control a button that point to our 'admin' view. It works fine for me and my collegue who have permission to see the button (we're the only two that should). However when any other user attempts to open a new form, they get the error "You do not have permissions to access a SharePoint list that contains data required for this form to function correctly."

Chblond said...

Very Great Article !!
Thank's to share your experience :)

But it seems that it can't be used if a user has the rights to see the two buttons. Have you a solution for that ?

Chblond said...

I found the solution. I created a field text to concat the vlues of the list, something like that : substring-after(eval(eval(Droits; 'concat(",", .)'); ".."); ",")
In the rule I tested if the fields contain the value Save or publish (like if Rights Fields does not contain Save I hide the button)

mohan ram said...
This comment has been removed by the author.
mohan ram said...

Excellent article man !!!

AW said...

This is a great technique.

Yet, I seem to be running into several issues.

In my button list I have 3 items. Admin,Save and Submit.

If I log into SP the correct use can only see the items that they should i.e. Admin and Save.

On my form all buttons have the rules ButtonName not equal to X - hide this control.

If my user has access to two buttons. They seem to cancel either other out so that on the form he sees no buttons. Yet it I remove him from one list, he can then see one button.

It is as if the conditional formatting rules cancel out each other.

AW said...

To get around this I had to add a form load rule to set a another field value. i.e. SaveAccess to equal 1. I think hid the button based on that value.

aparna john said...
This comment has been removed by a blog administrator.
Matthew Graziano-Humphrey said...

Wonderful! exactly what I needed.

I did have one small issue that wasn't permissions or form rule based.

I had to change the condition to Title 'does not contain' rather than Title 'Is Not Equal To' to get it to do a string compare

DRM said...

how to change this error you dont have permission to access sharepoint list which contains data required for this form to function correctly in infopath 2010 admin approval form........... pls answer my issue

jeremy said...

Thanks for posting this! It's very helpful.

Unknown said...

Thnx Chblond, you made my day!

steve said...

Remember to set permissions for the buttons at the list ITEM level, not at the list level. Permissions for the button list in sharepoint should be for ALL users that use form, permissions should be set at item level, one for save, one for submit. So, list allows all form users access preventing this message. Permissions are set on the item level in this list.

Carlopher Jay Sarmiento said...

Hi AW,

I'm having the same issue as yours. Could you elaborate more or give step by step procedure on what did you do on the form load rule?

littleghost82 said...

I have it set up the way you told me, checked the rights and they worked.
Now, i've set up the rules on sections but that is where it goes wrong: It is a littel over enthausiastic! It hides the sections perfectly but even I (as admin of both groups and the list) do not get to see them!
I read Chblond's post, which seems to be my problem as well, but I'm not sure how to do that... can someone help me with that?

littleghost82 said...

Chblond, Can you help me out?
I seem to be having the same problem (Should see both but only see the limited "version") but I'm not sure hoe to use your answer :(

littleghost82 said...

Tried the methode as explained in the link at the top of this page and that works! It's very technical and not very transparent but at least it works.
If it is possible to get the option explained on this page to work (with users being in several lists) then please tell me how! Rather use that because of ease of maintenance for 3rd party users/admins.

Uralska 4 said...

This solution worked for me, thanks!!
- create a single line text box on form
- in its properties, set the default value to substring-after(eval(eval(ButtonName, 'concat(",", .)'), ".."), ",")

And that's it :)
I just had to replace semicolons from Chblond's formula with commas.

Good luck

Pradeep Kumar said...

It's great. Thank you for posting.

Jamie Bray said...

Jan - Thank you, we needed this solution in 365 and your formula worked perfectly. Quick point to note where it says ButtonName in the formula, change that to your 'title' in the secondary datasource and it will pull through all the items in the list.

Post a Comment