none
why some MSDN links mention that we can NOT get the user who cause an After (asynchronously) event receiver to get executed. while based on my test i can get the user who cause the event receiver to fire in multiple approaches RRS feed

  • Question

  • I have the following event receiver inside my sharepoint server 2013, the event receiver get fired when an item is updated and i am running it with Elevated Privileges :-

    public override void ItemUpdated(SPItemEventProperties properties)
            {
    
                base.ItemUpdated(properties);
                SPSecurity.RunWithElevatedPrivileges(delegate()
                    {
                        using (SPSite site = new SPSite(properties.SiteId))
                        {
                            string currenweburl = properties.RelativeWebUrl;
                            using (SPWeb spCurrentSite = site.OpenWeb(currenweburl))
                            { 

    now i was reading this MSDN question link which get me confused... As the link mentioned that for the After event receiver (as in the ItemUpdated case) i can not get the user who cause the event receiver to fire, here is one of the answers :-

    'After' event such as Added, Updated, Deleted are run asynchronously under the system account, and so you won't have access to the user that triggered the event.

    but in my case i am able to get the ID of the user who cause the event receiver to fire as follow:-

    var currentusername = properties.CurrentUserId;

    Also i am able to get the loginName as follow:-

    var test = properties.Web.CurrentUser.LoginName.ToString();


    so can anyone advice why inside the MSDN link they mentioned that on the After event receivers i can not get the user who cause the event receiver to fire,, but based on my test i am able to do so !!

    now one note i have is that the MSDN link is back to 2010,, which means that it is not talking about sharepoint 2013, where in my case i am using sharepoint 2013..

    Saturday, January 14, 2017 4:02 AM

All replies

  • Hi John,

    The link you provided is in SharePoint 2007(MOSS 2007) forum, it is unmarked and not official document.

    I tested in my SharePoint 2013 test environment, it also works.

    Best Regards,

    Dennis


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, January 16, 2017 9:03 AM
    Moderator
  • Hi John,

    The link you provided is in SharePoint 2007(MOSS 2007) forum, it is unmarked and not official document.

    I tested in my SharePoint 2013 test environment, it also works.

    Best Regards,

    Dennis


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    so in sharepoint 2013 what are the main differences between Synchronous and Asynchronous event receivers ??

    as based on my test & also based on your test the ItemUpdated event receiver (which should run in Async mode) have the following 2 features which should be only part of synchronous event receivers:-

    1. it execute under the current user and not under the system account.

    2. i am able to get the current username and ID.

    so in SP2013 is there any differences / or what are the differences, between Synchronous and Asynchronous event receivers??

    second question .. now to be on the safe side and make sure my event receiver will always run under the current user account and i am always able to get the current user ID & current user name ,, so is it better to explicitly add

     <Synchronization>Synchronous</Synchronization>
    tag inside my element.xml file?as currently my .xml file does not have any <Synchronization>tag?


    • Edited by johnjohn11 Monday, January 16, 2017 12:09 PM
    Monday, January 16, 2017 12:01 PM
  • Hi,
               
    Synchronous Events
    A synchronous event is executed in the same thread in which the triggering action is occurring. For example, when the user adds an item from the SharePoint user interface, the event is fully executed before returning to the user and showing that the item was added.
    All Before events are synchronous events.

    Asynchronous Events            
    An asynchronous event occurs at a later time than the action that triggered it, and it executes on a thread that is different from the one in which the triggering action is running. For example, when a user adds an item to a document library by using the SharePoint user interface, the event starts to execute before returning control to the user; however, there is no guarantee that the event receiver will finish executing before we show the user that the item has been added.

    More information is here:

    https://msdn.microsoft.com/en-us/library/office/gg749858(v=office.14).aspx

    About your second question, please check the MSDN blog below:

    https://blogs.msdn.microsoft.com/unsharepoint/2010/11/09/sharepoint-event-receivers-making-asynchronous-event-synchronous-to-avoid-save-conflict-error/

    Best Regards,

    Dennis


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, January 17, 2017 8:37 AM
    Moderator
  • Hi,
               
    Synchronous Events
    A synchronous event is executed in the same thread in which the triggering action is occurring. For example, when the user adds an item from the SharePoint user interface, the event is fully executed before returning to the user and showing that the item was added.
    All Before events are synchronous events.

    Asynchronous Events            
    An asynchronous event occurs at a later time than the action that triggered it, and it executes on a thread that is different from the one in which the triggering action is running. For example, when a user adds an item to a document library by using the SharePoint user interface, the event starts to execute before returning control to the user; however, there is no guarantee that the event receiver will finish executing before we show the user that the item has been added.

    More information is here:

    https://msdn.microsoft.com/en-us/library/office/gg749858(v=office.14).aspx

    About your second question, please check the MSDN blog below:

    https://blogs.msdn.microsoft.com/unsharepoint/2010/11/09/sharepoint-event-receivers-making-asynchronous-event-synchronous-to-avoid-save-conflict-error/

    Best Regards,

    Dennis


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    thanks for the reply.. so from your reply you are saying that Sync and Async event receivers are almost the same, where i can get these info from them:-

    1. current user ID and current username.

    2. runs under the user permission .So incase the user action caused the event receiver to fire, the ER will run under the user permssion.

    but the only difference is that on Sync ER it will run under the same same thread , while in the Async ER it will run on a new thread.. so when it comes to coding and available properties , then both Sync & Async will provide the same properties and data ,, i this correct ? but will only differ how they are internally being handles (either using the same thread or on a new thread ) is this correct?

    Tuesday, January 17, 2017 11:47 AM
  • Hi,

    If you want to get  current user ID and current username and do SPSecurity.RunWithElevatedPrivileges, you can achieve it in ItemUpdated method.

    Best Regards,

    Dennis


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, January 18, 2017 2:48 AM
    Moderator
  • Hi,

    If you want to get  current user ID and current username and do SPSecurity.RunWithElevatedPrivileges, you can achieve it in ItemUpdated method.

    Best Regards,

    Dennis


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    so you mean my appraoch is valid .. is this correct?
    Wednesday, January 18, 2017 12:32 PM