Couple days ago, I published the Team Alert project on CodePlex.
It is a server side extension for TFS 2010, which allows you sending E-Mail notifications to any person field in
the event, regardless the field contain a SID, account name or display name. Of course, you may configure it to
send notification to fixed E-Mail addresses too.
I have described some situations that you may want to notify contextual users in my previous
post. Here is a quick comparison between
Project Alerts, Alert Editor and Team Alert.
|Project Alerts||Alert Editor||Team Alert
|Supported Events||WIC, C, BC, BSC||BC, BRSC, C, WIC, BSC||BC, WIC
|Delivery Type||Html, Plain Text, SOAP||Html, Plain Text, SOAP||Html, Plain Text
|Work Item Custom Fields||Not Supported||Not Supported||Supported
|Person Fields as Recipients||Not Supported||Not Supported||Supported
|Configuration||Team Explorer, TFS Web Access||Team Explorer with Power Tool||Configuration File
Apparently, Team Alert is not a replacement of any of these tools. At least, it does not provide any client
side subscription tool yet, but it does have additional features that I need.
Now, let's see how to configure it. Download the binary from CodePlex,
and then replace the configuration file with the following. Note that we specified that we want to attach the event XML.
<?xml version="1.0" encoding="utf-8" ?>
<section name="teamAlert" type="Dymetis.TeamAlert.Configuration.TeamAlertConfigurationSection, Dymetis.TeamAlert"/>
Copy the assembly and configuration to the TFS Plugins folder, such as X:\Program Files\Microsoft Team Foundation Server 2010\Application
Tier\Web Services\bin\Plugins. TFS will restart automatically.
Once any work item changed, you should receive an E-Mail like this:
If you open the attached XML, it should contain all core fields, changed fields, text fields, and custom fields, if there is any. Now we
got the sample XML, writing the XPath for filter expression is a piece of cake. Alternately, you can check out the schema in tbl_EventType
table, just keep in mind that the CustomField element is appended by Team Alert as a work around.
If you start wonder how it helps, let's say we use TFS as Bug tracking system. And in the case of a bug get updated by developers,
the reporter of the bug should be notified. Normally, you may need to subscribe each reporter to the WorkItemChangedEvent,
or write a custom SOAP web service for this.
Here is how you to achieve this with Team Alert. First, an expression is defined to filter events. The first half will limit the
work item to bugs only, and the second half will prevent the reporter get notify for his/her own changes. The only different between
this and VSEFL is a dollar sign is added in front of each field. (This may not be the only different, because it seems VSEFL doesn't
allow you specify a field on the right side of Boolean operators based on its definition,
but the March release of TFS power tool do put fields on both sides.)
Then we specify the recipient to be the user of this field:
The whole alert configuration element will look like this:
filterExpression="$"CoreFields/StringFields/Field[ReferenceName='System.WorkItemType']/NewValue" = Bug AND $"CoreFields/StringFields/Field[ReferenceName='System.AuthorizedAs']/NewValue" <> $"CoreFields/StringFields/Field[ReferenceName='System.CreatedBy']/NewValue"">
And now, all you have to do it wait for something happen, and confirm that the guys are getting notifications.
If you didn't receive E-Mails, check the event log on the server of TFS, or use the first configuration to
get the XML and test your XPath.
Thank you for reading. Feedbacks and suggestions are welcome.