Remote Event Receivers: Identify when a document's metadata is first completed

Document events are a perennial problem in SharePoint. This is, in part, due to the way documents are put into SharePoint:

  • You upload the document into SharePoint…
  • …which fires ItemAdded …
  • …then you complete the metadata…
  • …which fires item updated.

So, my problem was that our customer wanted an email sent when a document was first ‘added’ to SharePoint – except that by added they meant “Has been uploaded and it’s metadata completed for the first time”. While SharePoint does, technically, fire the correct events at the correct times, it’s pretty easy to see this ‘business event’ is probably more useful. Continue reading “Remote Event Receivers: Identify when a document's metadata is first completed”

Advertisement
Remote Event Receivers: Identify when a document's metadata is first completed

Register Remote Event Receivers on the HOST web

The project that I’m working on requires that I add remote event receivers to the host web for my Provider-hosted app. This is a little unusual – most of the stuff I found about remote event receivers was using the app web. It turns out, though, that it is possible, and there is a good explanation of how it works by Johnny Tordgeman on CodeProject. Rather than repeat all he’s said, I suggest you take a look. I just want to expand on some of the things I learnt doing this, that he didn’t mention. Continue reading “Register Remote Event Receivers on the HOST web”

Register Remote Event Receivers on the HOST web

BeforeProperties and AfterProperties

I am sick of having to hunt down the link to Synergy’s post on the BeforeProperties and AfterProperties available in different events on SPListItems. For my reference, here it is:

List:

List BeforeProperties AfterProperties properties.ListItem
ItemAdding No value New value Null
ItemAdded No value New value New value
ItemUpdating No value Changed value Original value
ItemUpdated No value Changed value Changed value
ItemDeleting No value No value Original value
ItemDeleted No value No value Null

Document Library:

Library BeforeProperties AfterProperties properties.ListItem
ItemAdding No value No value Null
ItemAdded No value No value New value
ItemUpdating Original value Changed value Original value
ItemUpdated Original value Changed value Changed value
ItemDeleting No value No value Original value
ItemDeleted No value No value Null

Note: Allegedly, this does change if the event receiver is synchronous – the before properties are available. I’ve not checked this out yet.

Obviously, for SharePoint 2007 systems that doesn’t apply – as ‘*ed’ event receivers are always asynchronous.

BeforeProperties and AfterProperties

Delete Event Receiver from a Content Type with Code

SharePoint allows you to attach event receivers to content types. That’s pretty handy. Unfortunately, deleting event receivers from those content types is much more hard. Perhaps this is why the Document ID feature fails to remove the content types that it adds. However, here is one possible approach.

SPContentType ctype = site.RootWeb.ContentTypes[SPBuiltInContentTypeId.Document];
if (ctype != null)
{
 if (ctype.EventReceivers != null)
 {
   bool bContinueDelete = true;
   while (bContinueDelete)
   {
     if (ctype.EventReceivers.Count < 1)
     {
       bContinueDelete = false;
     }
     else
     {
     bool bFoundOne = false;
     foreach (SPEventReceiverDefinition d in ctype.EventReceivers)
     {
         //Could match on the Type of the event receiver, but for this example, let's use name
         if (d.Name.Contains("Document ID"))
         {
           d.Delete();
           ctype.Update(true, false);
           bFoundOne = true;
           break;
         }
     }
     if (!bFoundOne)
     {
       bContinueDelete = false;
     }
   }
 }
}

More on why this is important in a later post.

Delete Event Receiver from a Content Type with Code

How DisableEventFiring / EventFiringEnabled works

I’ve got an event handler on a SharePoint list that’s fairly long running, and this then raised a question in the office – do these settings control event firing for the currently running event handler, or for the entire list?

Very often you see lines of code like this…

this.EventFiringEnabled = false;
item.Update();
this.EventFiringEnabled = true;

… but was this really necessary? Are people worried about events not being handled ‘cos firing is disabled, or is this just a convenient way of tracking whether events are enabled or not? Continue reading “How DisableEventFiring / EventFiringEnabled works”

How DisableEventFiring / EventFiringEnabled works

Registering EventHandlers against ContentTypes

In SharePoint, Event Handlers (or Event Receivers – whichever terminology, a child of SPItemEventReceiver) can be registered against lists/libraries. You can do this through an SPWeb (site) scoped feature, declaratively or programmatically with an SPEventReceiverDefinition.

Unfortunately, you can’t declaratively register event receivers at the SPSite (Site collection) level – which would be fantastic – just turn on the feature and across all your site collection lists/libraries of a give type would get additional event receivers. Personally, I think this may be a bug; I don’t see why this shouldn’t work at the SPSite level.

Anyway, there is still another option – we could register our event against a particular Content Type. This is a less often used approach, which raises two questions – how do you do it, and what happens to child Content Types? Continue reading “Registering EventHandlers against ContentTypes”

Registering EventHandlers against ContentTypes