Work Item Notification

Description

A common feature of issue tracking systems such as Team Foundation Server's work item tracking module is the ability to send e-mail notifications to users when important changes are made to work items.

Team Foundation Server includes two built-in mechanisms for e-mail notifications. The first is the Project Alerts functionality, but this allows only very limited capabilities for subscribing to work item changes. The second method involves using the bissubscribe.exe command line tool combined with some XPath expressions which allows the user to use more complex rules than is available using the Project Alerts feature. The second method is a bit obscure and requires the end-user to have a fair amount of internal knowledge of TFS work items and work item events in order to author the necessary XPath expressions.

Our client desired a simpler method of creating e-mail notification subscriptions, but still needed a solution that would allow them to enter complex notification conditions.

Solution:

After researching various possible solutions, we concluded that the best way to provide the desired functionality, while keeping the solution both flexible and easy to change, was with a custom web service that was configured to "listen" for WorkItemChangedEvents. This is very similar to the solution we used for the auto-assignment project.

As a starting poing for our work, we downloaded and investigated the TFS Event Handler project available on CodePlex. We desired to make two important changes, however. First, the TFS Event Handler project is based on VB.NET source code, and our client desired a solution authored in C#. Second, extending the TFS Event Handler project requires one to author a new class in VB.NET, and recompile and redeploy the resulting assembly. We desired a solution whereby the client could make ad-hoc notification rule changes without the hassle of recompiling the source code.

We therefore extended the rules engine that we had already written for the auto-assignment project, and created new rules and actions that could handle e-mail notification conditions. The rules file was authored in an XML configuration file, which is read in when the web service starts.

To add new notification rules, the user need only edit the configuration file. The web service automatically scans the configuration file for changes, and automatically reloads any rules that are added after the web service is started. Thus there is no need to recompile, redeploy, or restart the web service in order for new rules to take affect.