I know that there are so many articles about this topic, but many of them were too complicated for many people to understand and most of the available articles only work with Classic authentication and not claims.

I have a group called MYInfopathGroup in which I want to check if the current user is part of that SharePoint group. Below are the fields to show you how it look like.

First we need to retrieve the Account Name of the current logged in User. We can retrieve this information by using userprofileservice.asmx, Below are the steps to create the data connection. I am going to write a detailed article about how to retrieve the Account Name.

Remove the second double click to insert field and replace it with“ABCDEFGHIJKLMNOPQRSTUVWXYZ” (incl. the quotiation marks)

Remove the third double click to insert field and replace it with “abcdefghijklmnopqrstuvwxyz”(incl. the quotiation marks)

The function should now look as follows:translate(double click to insert field; “ABCDEFGHIJKLMNOPQRSTUVWXYZ”; “abcdefghijklmnopqrstuvwxyz”)

For the first parameter double click on double click to insert field

From the drop down select the GetUserProfileByName data source

Expand the dataFields group as shown in the screenshot and select Value

Select the filter data and the filter should look like this.

At this stage the form queries the current user’s account name and stores it in the username field on form open. The forms runs fine on the InfoPath client but when we use the same form in the browser we get Access denied.

To over come this issue you need to Convert the data connection to Udcx file. We can achieve this by just clicking on the Convert to Connection file button available on the Data Connections.

Go to the data connection library and open the file in notepad and uncomment the udc:Authentication tag in the generated data connection udcx file.

Below is the sample tag

<udc:Authentication>

<udc:SSO AppId=’InfoPathWebService’ CredentialType=’NTLM’ />

</udc:Authentication>

Next we will query the UserGroup web service to get us a list of users in a specific SharePoint group:

The UserGroup web service contains a method “GetUserCollectionFromGroup” which we will use in our setup:

In the next screen select Set Sample Value and provide InfoPath with the name of the group you want to query (e.g. if your user is in a SharePoint group “Test” put in “Test“)

Click Next

Provide InfoPath with the same group name in the next screen and click Next again

Click Next

Use the default settings, click Finish and close the dialog window

We need to save our form and then use the Export Source Files option under “Publish“ tab.

Once that is done, close the form and navigate to the location where you exported your form to. Open the file named “GetUserCollectionFromGroup1.xsd“. This file defines the XML schema. Open the file in Notepad++ or Visual Studio

<s:complexTypename="GetUserCollectionFromGroupType"><s:sequence><s:elementminOccurs="0"maxOccurs="1"name="Users"><s:complexType><s:sequence><s:elementmaxOccurs="unbounded"name="User"><s:complexType><s:attributename="Notes"type="s:string"></s:attribute><s:attributename="Name"type="s:string"></s:attribute><s:attributename="IsSiteAdmin"type="s:string"></s:attribute><s:attributename="Sid"type="s:string"></s:attribute><s:attributename="ID"type="s:string"></s:attribute><s:attributename="LoginName"type="s:string"></s:attribute><s:attributename="Email"type="s:string"></s:attribute><s:attributename="IsDomainGroup"type="s:string"></s:attribute></s:complexType></s:element></s:sequence></s:complexType></s:element></s:sequence></s:complexType>
Now locate the following piece of code within your file:
and replace it with this:

BeforeProperties and AfterProperties: SPItemEventReceiver

There are two type of SharePoint events: Asynchronous (After) and Synchronous (Along) events.Synchronous events, e.g. are: ItemAdding, FieldUpdating, FeatureDeactivating etc… (like all those events that are having “-ing” as suffix).Asynchronous events, e.g. are: ItemAdded, FieldUpdated, FeatureActivated etc… (like all those events that are having “-ed” as suffix).

As far as AfterProperties and BeforeProperties are concerned for any event, they can help you to extract After and Before change in state about the object in context. This case is true and valid for any document library in context. For example, if you want to prevent any change in particular column of Document library your code must be:

But such examples are only valid for Document Library in context, as per the Microsoft; as it is written inSDK that “For documents, Before and After properties are guaranteed for post events, such as ItemUpdated, but Before properties are not available for post events on list items”. So, statement written like these form the basis of analysis, on testing various events during Addition, Deletion and Update of both SharePoint lists and SharePoint library, here is the conclusion that is actually drawn for any List:

List

BeforeProperties

AfterProperties

properties.ListItem

ItemAdding

No value

New value

Null

ItemAdded

No value

New value

New value

ItemUpdating

No value

Changed value

Original value

ItemUpdated

No value

Changed value

Changed value

ItemDeleting

No value

No value

Original value

ItemDeleted

No value

No value

Null

No value means that column value in the hash table was not available.
New value means that the correct value for the column was available.
Changed value means that the correct updated value was available.
Original value means that the correct original value was available.

Here is the results on any document library:

Library

BeforeProperties

AfterProperties

properties.ListItem

ItemAdding

No value

No value

Null

ItemAdded

No value

No value

New value

ItemUpdating

Original value

Changed value

Original value

ItemUpdated

Original value

Changed value

Changed value

ItemDeleting

No value

No value

Original value

ItemDeleted

No value

No value

Null

Properties.ListItem refers the the current value for the list item at that point in the event. Null means that the item is not available.

Some noteworthy points are:

Not surprisingly, we get null values for for ItemAdding (before item is added) and ItemDeleted (after item is deleted).

As correctly documented in the SDK, item events for lists do not expose BeforeProperties.

ItemAdding and ItemAdded correctly report the value in the AfterProperties for an list item, but not a library item. This is curious.

We have no visibility on the previous states during the ItemDeleted event. Once it’s deleted, it’s clearly gone.

So, if we go back to our original problem listed above. How can we prevent a user from changing a certain column for an item in a list event? From the list table, you can see if we hook into the ItemUpdating event, we can compare the current item’s value (properties.ListItem) to the AfterProperties value. The code would look like this: