On the week I got a task for creating a simple routing workflow. Forms including different pieces of information are submitted by users and this data must be approved by another users. The workflow itself is not important here, the main point is that the data submitted is different but the workflow should be common.
We already solved similar workflows utilizing item event receiver, but in that cases the receiver was bound to the list. Now I planned that the workflow would be associated with a parent content type that would contain only the fields required by the workflow, and child content types would be “inherited” from the parent to add form data.
It sounds good, but to tell the truth I’ve never tried that before and found no information on the web (except this MSDN forum thread after my tests) about whether the event receiver settings would be propagated to child content types or not.
So, I’ve created a simple event receiver that only trace out the content type information of the new item when it was added to the list:
Next, I’ve created a new content type called EventReceiverParent on the UI derived from the Item parent content type, and registered the event receiver using a simple command line tool.
Where the RegisterContentTypeReceiver method looks like this:
The DisplayContentTypeReceivers displays the event receiver registration for the specified content type:
After this, I’ve created a child content type called EventReceiverChild on the UI, and displayed the event receivers for that:
The result showed that the receiver information was inherited to the child content type.
I found the same, when created another child content type called called EventReceiverChild2 using code:
AddContentType(web, "EventReceiverParent", "EventReceiverChild2");
Where the AddContentType method looks like this:
When you register a new event receiver for the parent content type, and update the content type using the Update() or Update(false) method instead of Update(true), then I found that the changes are not propagated down to the children content types.
When I assigned the content types to a list, and created new items for each of the content types, I found that the event receiver is triggered for each and the name of the right content type is traced out.
The result of my tests shows that utilizing an event receiver bound to a parent content type is a practical way to create simple workflows for children content types.
Note, that I made the tests on SharePoint 2010. There might be differences when you work on WSS 3.0 / MOSS 2007.