1

I am working on a remote event receiver for a custom list inside our SharePoint online site collection. and I have noted that when editing an item inside the modern UI >> the following fields will not be inside the properties.ItemEventProperties.AfterProperties unless the users modify their values:-

  1. multiple lines of text

  2. Number

  3. Drop-down list

while in Classic mode those fields' types will always be presented inside the properties.ItemEventProperties.AfterProperties, even if the user did not modify them:-

  1. Date/Time.

  2. Managed metadata

  3. single line of text

So can anyone advise if my observation is correct? any what is the reason behind this issue?

  • 1
    I have not directly compared them like you just did, but that does not surprise me. In general, event receivers are only supposed to send afterproperties for values that have changed. You can test that explicitly if you update a single field on an item through PowerShell and check the triggered event, you will only get that one field. But the classic UI gives on old-school aspx form that posts back every value in the form regardless of whether the user made a change, so they all come through the receiver. I suspect the ajax-y nature of the modern form means it is being a little more selective. – willman Mar 4 at 1:36
  • Is the Item updated through code? – Litt Spector Mar 6 at 13:30
  • @LittSpector as mentioned in my question i am updating the item using classic and Modern UI, – SharePoint TestDev Mar 7 at 23:31
  • Just a reminder that the points you put up for bounty will disappear into the "ether" if you do not accept an answer: meta.stackexchange.com/questions/76137/… – willman Mar 12 at 20:45
1
+50

The AfterProperties of an event receiver, whether an old-school server-side Receiver or a RemoteEventReceiver, will always only contain the values that were submitted to SharePoint. In the case of an update made via code through one of the APIs, this is usually just the small number of fields that are being changed, most of the other values do not get Posted or submitted to SharePoint. In those cases, you can be guaranteed to only have the changed values in the AfterProperties.

Classic-mode SharePoint sites use ASP.NET WebForms and a "traditional" postback when the user clicks the "Save" button. This means that even if the user didn't modify a single value on the Form, if they hit "Save", every field visible on the form gets Posted back to the server and will all appear in the AfterProperties, even if they are identical to the previously saved values on the Item.

Modern-mode sites fall somewhere in the middle -- and if you build a PowerApp replacement, depending on how you configure it, it will behave slightly differently. The modern item form only makes fields editable when a user clicks on them, and depending on the type of item, it may even auto-save each changed value as the user moves from field to field, saving each one independently.

Even before the introduction of modern list forms, a well designed Event Receiver needed to build code to accommodate the possibilities that values may or may not be in the AfterProperties. Having a mixture of classic and modern sites may make the problem more pronounced, but it is technically not a "new" problem. Regardless of what type of site you are responding to, use these guiding principals to ensure that your EventReceiver will work in all scenarios:

  • If you are building code that needs to check if a certain field or fields were changed, first check if it even exists in the AfterProperties, because if not, then you know it didn't change. If it does exist, you still need to compare that value to the same in the BeforeProperties to see whether it actually changed or was just a identical value re-posted.
  • If you are building code that needs to do something with a specific field regardless of whether it was changed, then just forget about AfterProperties and always grab a reference to the actual ListItem. If you are doing a synchronous EventReceiver where the ListItem hasn't been updated yet, you can always check for existence of the field value in AfterProperties first, and if it is not present, then grab the ListItem.
| improve this answer | |
-1

This is the OOTB behavior of SharePoint in the case of ItemUpdated. In my case, there was a custom web part that was updating the item.

As mentioned in Handle list item events in the provider-hosted add-in

SharePoint behaves a little differently when the item updated event is triggered by a programmatic update: it only includes in the AfterProperties the fields that changed in the update

The same you can check in the table given in the below URL.

BeforeProperties and AfterProperties of the SPItemEventReceiver

| improve this answer | |
  • 2
    Technically speaking, the behavior of the Event Receiver is not different, it is the behavior of the method of posting the data. The Event Receiver's Before and After Properties ALWAYS only includes the properties that were saved to the item. The problem is that the classic form post Saves every value in the form, even if the user didn't modify their values. – willman Mar 6 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.