Zieglers

Just little about C#, .NET, SQL Server, SharePoint and SAP

Event Receiver not firing when document is created using Office

Posted by zieglers on July 7, 2010

Problem Description:

If you create a new document using Office client applications (such as Word, Excel, PowerPoint) and save it into SharePoint, event receivers do not fire. 

Common belief: This is because “adds from Office only fire ItemAdded, not ItemUpdated”. (Please note that this statement is not correct.)

Correction: Adds from Office client applications fire all registered event receivers at all times. However, since they fire with security context of triggering user (normal users), most of the time that user has no admin rights to perform operations such as creating subsite, modifying site, web objects, sending email … etc. This makes users think that event receivers do not fire.

Here are all item events:

  • ItemAdded
  • ItemAdding
  • ItemAttachmentAdded
  • ItemAttachmentAdding
  • ItemAttachmentDeleted
  • ItemAttachmentDeleting
  • ItemCheckedIn
  • ItemCheckedOut
  • ItemCheckingIn
  • ItemCheckingOut
  • ItemDeleted
  • ItemDeleting
  • ItemFileConverted
  • ItemFileMoved
  • ItemFileMoving
  • ItemUncheckedOut
  • ItemUncheckingOut
  • ItemUpdated
  • ItemUpdating

Let’s take a look at the sequence event are fired. 

While uploading a new document in SharePoint library:

Case-1: If a document library does not force check-out, here is the sequence of item events fired.

Case-2: If a document library forces check-out, here is the sequence of item events fired.

Note: ‘..ing’ events are sync before-events. ‘…ed’ events are asynch after-events.

While creating a new document using Office client applications:

(such as Word, Excel, PowerPoint)

Case-1: If a document library does not force check-out, here is the sequence of item events fired.

Case-2: If a document library forces check-out, here is the sequence of item events fired.

Demo:

Let’s deep dive into the issue: 

Event Receiver not firing while adding a document using Office client applications”

In this demo, I’ll have a code snippet to update current web’s description each time an event fires as seen below.

Doing so, not only we get to see which events fire but also we’ll observe the sequence they fire. Remember before-events are sync events, however after-events are asynch events. This means that execution sequence of after-events may vary with different executions of same code.

Usage-1: No Try-Catch, opening web object from event properties object

Create a new document

Type something and save it

Debug and put a breakpoint at web.Update().

Go ahead and execute this line, you’ll see that an exception is thrown.

Important Finding:

Reason we get a security exception here is that event receiver’s ‘properties’ object was created using current user who has no privileges to update web object.

Misleading fact:

Since there is no exception handling here, thrown exception is not caught by event receiver code. Execution continues and end-user gets no exception, which makes end-user think event receiver is not firing.

What to do:

Always use exception handling in your event receiver code. Handle any exceptions thrown accordingly.

 

Usage-2: Using Try-Catch, opening web object from event properties object

Follow same steps above to create a test doc. This time we’ll catch the exception.

Now, we are aware that something went wrong. It’s an “Access Denied” error, due to security context of current user. Current user has no rights to modify web object, which is normal behavior to expect.

Usage-3: Using Try-Catch, opening web object from event properties object, and running code with elevated privileges

This time let’s try to run the code with elevated privileges to solve security context problem.

Again, create another test document and debug.

Now, we see here something really interesting:

Access Denied error while running with Elevated Privileges!!!

Important Finding:

Even though code is run with elevated privileges, we still get a security exception. This is because event receiver’s ‘properties’ object is still created using current user’s security context.

Misleading fact:

Running code with elevated privileges does NOT always guarantee that you will not get an “Access Denied” error. Security context of objects are still to be checked even though your code executes with elevated privileges.

What to do:

Always use ‘Using’ clauses when running your code with Elevated Privileges in order to avoid security related exceptions.


Usage-4: Using Try-Catch, opening web object using ‘Using’ clauses, and running code with elevated privileges

Finally, let’s add using clauses to the code. Doing so, we ensure that a brand new web object is created while running code with elevated privileges.

Create another test document and debug.

As seen above, this time web.Update() method is executed successfully!

Also, web description has been updated.  🙂

zieglers

Advertisements

2 Responses to “Event Receiver not firing when document is created using Office”

  1. aasaichess said

    Really very nice, lot of thanks to you..

  2. zzz.net.ru said

    zzz.net.ru

    Event Receiver not firing when document is created using Office « Zieglers

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: