Itemupdating beforeproperties null
Now with some help, I realize that mainly the code just has to be written a certain way - but it’s also true to say that there is a limitation which can affect some things you might want to do.
In any case, this is a gotcha that I’m starting to see other people hit so I think it’s worth talking about it.
Damon gives just one example of a poisoned dagger in the game of Sharepoint Development: The Item Event Receiver.
I’m usually disappointed when writers employ oft-overused metaphors to describe a situation.
I don’t mean that it’s largest and most luxurious application every written, but rather that you may be cruising headlong into a nasty rendezvous with an iceberg that could deal a severe blow to your project.
We may never know about all of the dangers lurking out there, but today we’re going to cover at least one danger you may encounter while writing event receivers – an annoying issue with the Item Updating and Item Updated events firing twice.
With that in mind, Share Point 2010 is like a sea of icebergs – there is a lot going on under the surface that you may not notice until it’s too late.
Unfortunately, that makes your project like the Titanic.
Perhaps you need to create, update or delete an item somewhere, or perform some other action related to sites, users or data in Share Point. Before we dig into the “Why it happens” and “The workaround” sections, it’s worth reminding ourselves of some aspects of remote code and authentication in particular.
When accessing a user field in event receivers there are few differences in the returned values when Classic mode authentication is used from the value when Claims based authentication is used.
The difference is present in After Properties of Item Adding and Item Updating event.
Feel free to skip forward if you’re familiar with this territory.
For those just starting out with Remote Event Receivers (or Share Point apps/remote code in general), it’s worth noting that an app is required for any form of remote code.