Browser Forms

Re: Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

sdnmjn — Thu, 23 Feb 2017 19:00:43 GMT

Whew!!! So you're ideas about the SharePoint list was the way to go but the rules were a pain to figure out. So here's what my solution was.

I created a SharePoint list with a service department field, Service Owner (People/Group), Liaison (People/Group)

created a data connection in InfoPath to the SP list. On form load I added a rule to query the SP list data connection and a rule to set the current user.

I created a field (see pic below) to read the SP list for each People/Group column, one for each and added the default value of contains(AccountId[contains(., userName())], "\")

- this causes a read of the values of the People/Group column and compares it to the current user "username()". If the current user is in the list it returns a value of "true", if not then "false"

http://imgur.com/prMfbqS

For the control that I wanted to lock down or disable i implemented the following rule: if the value of the field "liaison" was not equal to and did not contain the value "true" - disable the control.

http://imgur.com/kpwLCiL

Sounds simple right?

Re: Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

Hilary Stoupa — Thu, 23 Feb 2017 15:41:52 GMT

Wonderful - have your users test & holler if you run into trouble. :)

Re: Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

sdnmjn — Thu, 23 Feb 2017 01:14:24 GMT

So far it seems to be working. I won't fully know until tomorrow until I have users other than me try it.

Re: Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

sdnmjn — Wed, 22 Feb 2017 17:23:05 GMT

It does. Thank you. I'll give it a shot and let you know how it works out.

Re: Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

Hilary Stoupa — Wed, 22 Feb 2017 17:15:33 GMT

Okay - so instead of using SharePoint groups for this, you'll have to add a SharePoint list to track who should have what permissions, unfortunately - and manually keep it updated. I'd probably have one column for the user & have that be a person / group type, so that you can make sure the user info in accurate - the AccountID field in your list data connection should then have the user's account ID, that you can compare to the user name function - you should probably drag that onto your form and check it in the browser so you can see the returned value of both that as well as a calculated value with the user name function - browser may return something different than filler / preview, so it will be better if you know in advance what the data looks like. For the other column, I'd call it something like "group" and make it a choice. Then in your form, you can find the row in the list that matches the user's user name and find their group. Hope that makes sense. :)

Re: Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

sdnmjn — Wed, 22 Feb 2017 16:56:31 GMT

Yes, I need to find out if the user was a member of the group.

We cannot use SOAP or REST because cross site scripting is disabled in our environment. So when I try to use the user profile service I get an error when the form loads. I can use the username() function though.

Re: Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

Hilary Stoupa — Wed, 22 Feb 2017 15:30:20 GMT

So - you'd need to find out if the user was a member of the group? What do you mean by "The SOAP service is not fully implemented on our site"? Are you saying you can't use the User Profile service to determine group membership?

Disabling functions based on SharePoint List Users and Groups (SP2013, IP2013)

sdnmjn — Tue, 21 Feb 2017 15:29:30 GMT

I've researched this and all I could find were examples for 2007 and 2010 which doesn't seem to work with 2013.

I have an InfoPath 2013 form with two views, default view and read only. Within the form there are sections where a user can enter data.

- There are three user groups (Submitter, Owner, Liaison) that will enter data and "everyone" can view but not enter data.

- These all currently exist as SP2013 site groups.

(a) I was told on other sites that I would have to create a SP list and recreate the groups and users in the list.

(b) Another site said I would only have to recreate the groups and permissions in the SP list.

The SOAP service is not fully implemented in our site.

So is either a or b correct?

How would the rule look in IP2013 to disable the control based on the SP list?

Thanks.