SharePoint Caveat – BeforeProperties in SharePoint workflow

I had to develop an application to track the status of delivery of an order whose details would be stored in a list. To accomplish this I had to choose either an event receiver or a workflow. I chose workflows since workflows would give me a better development environment with visual representation of the flow of process using which I can do the changes so easily which is not possible with event receivers.

Of course I chose to go ahead with Visual Studio workflow rather than SharePoint designer workflow due to the recursive process involved in the requirement.

I started my development and was so happy with the way it was progressing until I faced with a hurdle which led me to stop developing the workflow and instead start with an event receiver from scratch. I was really disappointed with that.

The requirement was to compare the values of a certain field before and after the list item has been updated. This can be achieved by creating 2 workflow properties to store the after properties and before properties of the list item.

The problem was when I found that BeforeProperties was always null in the ItemUpdated event activity and only the AfterProperties had values in it. I wondered why it is null always. When I tried the same workflow for a document library instead, I found that both BeforeProperties and AfterProperties to be holding values and were not null.

After googling I found that workflows for lists have the same limitation as that of event receivers for lists. And that is finding null value in the BeforeProperties for a list item in an ItemUpdated event receiver in a list. This limitation is present in both event receiver and workflow when attached to a SharePoint list. But you can overcome this limitation in an event receiver by replacing Item Updated event receiver with an Item Updating event receiver. In an Item updating event receiver you can find values in the BeforeProperties of the item that is getting updated. You can more about it over here. But in a workflow attached to a list there is no work around which means workflow is not going to be of much use for a list in this case.

Advertisements

Deploying a web level event receiver to a SharePoint web application

I was creating a web level event receiver which was to be deployed to a SharePoint web application which had more than 100 site collections. So I decided to create it as web application level scoped solution. But, only after I tried deploying it did I understand that a web level event receiver cannot be deployed at web application scope.

Somehow, I wanted to deploy the event receiver such that it gets executed for the site collections in a web application. I cannot manually activate the feature as there are more than 100 site collections.

It is then I got an idea that we can deploy the solution using a PowerShell script and activate the feature in all the site collections in the web application.

Here is a good blog post describing how to activate a feature in all the site collections in a web application using PowerShell script: http://basementjack.com/uncategorized/powershell-to-activate-a-sharepoint-2010-feature-on-every-site-collection-in-a-web-app/

But what if a user is creating a new site collection in the web application, and the feature also must get activated automatically instead of manually activating it in the newly created site collection? We can achieve this by creating a feature stapler.

A Feature stapler is a feature in itself which when deployed at a web application level (or at any level) will automatically activate a feature whose feature id is defined in the feature.xml of the feature stapler.

Here is a good blog post which explains how to create a feature stapler: http://blogs.msdn.com/b/kunal_mukherjee/archive/2011/01/11/feature-stapling-in-sharepoint-2010.aspx

SharePoint Caveats – 1: Redirecting in Item Deleting event receiver.

I have been working in SharePoint for the past 2 years. I have encountered numerous bugs in SharePoint which makes me bewildered about Microsoft’s carelessness. So, I have decided to write a series of blog posts about the bugs in SharePoint (2010).

This is my first post in the series. In this I’m going to describe the bug that I found in the Item Deleting event receiver in SharePoint compared to the Item Adding event receiver.

In SharePoint event receivers we have options to cancel an event from occurring. We can also redirect to an application page or a web part page after canceling the event from occurring.

Here is the code for Canceling an Item Adding event from occurring and redirecting to an Application page .

           properties.Cancel = true;
           properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
           properties.RedirectUrl = "/_layouts/DeletingEventReceiver/ErrorPage.aspx";
           this.EventFiringEnabled = false;

Let us see what is the bug in SharePoint event receiver with respect to the above coding.

1. Create an Event receiver project with Item adding and Item deleting event receivers targeting Document Library template..

2. Now, add an Application Page to your project.

3. In the Item Adding event receiver add the above code as shown below.

public override void ItemAdding(SPItemEventProperties properties)
       {
           base.ItemAdding(properties);

           properties.Cancel = true;
           properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
           properties.RedirectUrl = "/_layouts/DeletingEventReceiver/ErrorPage.aspx";
           this.EventFiringEnabled = false;
       }

4. Deploy the solution in to SharePoint. Go to any of the document libraries in your SharePoint site, add a document and you will see that you are being redirected to an application page as shown below.

Untitled

5. Now, comment the code in the Item Adding event receiver and copy & paste the same code in to the Item Deleting event receiver as shown below.

public override void ItemDeleting(SPItemEventProperties properties)
       {
           base.ItemDeleting(properties);

           properties.Cancel = true;
           properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
           properties.RedirectUrl = "/_layouts/DeletingEventReceiver/ErrorPage.aspx";
           this.EventFiringEnabled = false;
       }

Deploy the solution.

6. Now, go to any of the document libraries and try to delete a document by clicking the delete option in the context menu of the document or from the ribbon menu.

7. You will see that you are not being redirected to the application page (as shown below) as in Item Adding event receiver.Untitled

As you see above you are taken to the default SharePoint error page instead of the application page that we created.

Alright, fine do not panic we still have our code that we implemented above in the Item deleting event receiver functioning somewhere inside SharePoint.

I will show where.

In the context menu of the document click View Properties, you will see a pop up with the properties of the document. In the ribbon menu of the pop up click Delete Item as shown below.

Untitled

And now you will be taken to the custom Application page that we had created as below.
Untitled

Fine, we have successfully finished discussing about a SharePoint bug. Thanks

Update: This blog post was discussed  here in the SharePoint forum. As you can see there, an explanation was given by a Microsoft guy saying “While deleting an item, the HTTPContext may be null. In this case, the URL redirection might fail, and we treat CancelWithRedirctUrl as CancelWithError to show the error message to the user.“, that being said, will try to come with a solution.