Afeter Properties[“User Field”] is “-1;#i:0#.w|domain\user1” Because its happening only when adding and modifying a user field using the New and Edit form it seems that the problem is with the Peaple Editor control.For some reason it doesn’t work as well with claims based authentication as it does with classic authentication.

itemupdating itemupdated-59

How I solved it Googleing this helped me not one bit and my first solution was something I would like to hide at the bottom of some server (I don’t want to talk about it, let’s just say it had something to do with counting the seconds since the last update).

At your disposal on SPRemote Event Properties you have after Properties and before Properties, found by doing this: And those were the key to the problem: how to act on the firing only when the user changes something and not when it updates itself?

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.

This is true for Share Point 2010 and Share Point 2013 and its present only for custom lists but not for document libraries.

I’ve done some testing and the results are presented in this post. The test is performed when adding/changing/deleting the item’s user field using the UI (New and Edit form) and when adding/changing/deleting the field pragmatically.

The event receiver was nicely attached and got busy when I uploaded a document. I was trying to change permissions on an item and this was the part of my code that was creating the problems: Inside my SPRemote Event Type.

Item Updated I did an Update and making it trigger itself. If you’re dealing with a event receiver with access to server side code, this is not a problem.

Because of these differences it’s possible that your old code which has worked fine with classic authentication will not work with claims based authentication.