Custom Email Templates in TFS 2010

Team Foundation Server 2010 can create custom alerts that fit almost any set of criteria you can come up with, but the emails that it generates are pretty generic, though informative.  Wouldn’t it be great if you were able to customize the information that was contained in them and maybe even spice them up a little bit with corporate branding?  With just a little bit of work, you can have these looking much better.

On your server that is housing the TFS 2010 Application Tier, all of the e-mail templates are contained in the same folder where TFS Job Agent was installed.  In my case, the files are located at:

C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\TFSJobAgent\Transforms

There are many different templates here for different kinds of alerts, but for this example, we’ll concentrate on the normal Work Item alerts.  These are the ones that are used for alerts relating to Work Item changes, reassignment, and status updates, but there are others there for build alerts, checkins and the like.  These two files are:

  • WorkItemChangedEvent.xsl — This is the HTML version of the alert that is usually sent when the alert is triggered.
  • WorkItemChangedEvent.plaintextXsl — This is the plaintext version of the alert. 

Opening these files, you will see pretty standard XSL used the transform the TFS data into the alert e-mail.  For this example, let’s just add a header and create a link to the style sheet that I use for my custom process guidance to make sure the branding is identical across all communication with the end-users of the TFS instance.

So let’s modify the header and body of the e-mail to make things a bit more friendly…

<?xml version=“1.0” encoding=“UTF-8”?>
<xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform&#8221; version=”1.0″>
   <xsl:import href=“TeamFoundation.xsl”/>
   <!– Common TeamSystem elements –>
   <xsl:template match=“WorkItemChangedEvent”>
      <head>
      <!– Pull in the command style settings –>
      <xsl:call-template name=“style”>
      </xsl:call-template>
      <!– Link to the Company TFS Style Sheet –>
      <link href=http://processguidance.Company.com/Style/Content.css&#8221; type=“text/css” rel=“stylesheet” />
   </head>
<body>
      <!– Company Email header –>
   <div>
       <img height=“17” src=http://processguidance.Company.com/Images/EmailHeaderBar.png&#8221; />
      <br />
      <div>
         <div style=“float:left;”>
            <img alt=“Company Name” height=“40” src=http://processguidance.Company.com/Images/Company_logo.gif&#8221; width=“270” />
         </div>
      </div>
   </div>
<!– End Company Header–>

Now that we have some really basic markup in the header of the e-mail, our correspondence with the end-user will look much better.  Of course, you can dig a bit deeper to change the fields displayed in the alerts or add a footer.  Just make sure that you always have a backup of the original file and test test test!

Advertisements

TFS 2010 Rules Limited to 255 Characters

Using HTML fields in your TFS 2010 Work Item definitions gives you great flexibility for user input or storage of presentable information from external sources (System Info from Test Manager, for instance).  This is great if you need to input a lot of information with formatted text, hyperlinks, or even links out to external resources.  This is leaps and bounds over the text fields in previous versions.  One area where this falls short as in the TFS 2010 rules that are attached to the fields.  Don’t get me wrong, these work consistently and make life so much easier, but there is a huge missed opportunity here.

Using default values for these fields, it is possible to create blank tables and formatted headers to prompt the end users of the work items for well-formed input.  This makes the user experience so much better and gives you a much better chance of getting the information you want on the form.  The downside comes in the formatting of the rules.  While the HTML and PlainText data types are stored as blobs in the database, the rules are still stored as 255 character strings.  This is a little bit inconvenient.  The only good part here is that the HTML rendering in VisualStudio isn’t that particular and allows you to make shortcuts in your markup to make the message as short as possible.  After pulling the whitespace out you can usually come up with something that is at least usable, though you’ll have to sacrifice all of the fun styling and formatting you might otherwise have put in there.

Maybe that’ll be a feature for the next release?

Forming URLs in TFS WebpageControlOptions

The greatest thing about a technical blog is that it gives you an opportunity to memorialize dumb mistakes in the hope that it will show up in the first few search results when other run into the same issue rather than having to track through other pages that don’t quite match.  This is one of those cases. 

I have started to incorporate WebpageControl fields in my TFS 2010 WIT definitions to provide better process guidance, but also to provide dashboard-style feedback to the person filling out the form.  One of the neatest features is the ability to have the page post every time one of the WIT fields referenced in elements is changed.  This is especially useful if you are binding the to the current value before it is saved giving the use live feedback.  How cool is that?!

There I was, working my WIT mojo, only to end up with this unfortunate error:

Error importing work item type definition:
‘=’ is an unexpected token.  The expected token is ‘;’.  Line 203, position 176.

How annoying?

The only good part of this is that the fix is simple and really something I should have caught when updating the XML on the WIT definition.  In this case, the error came in having the ampersand symbol (&) in the URL as part of the querystring without translating it to & as I should have.  I like it when the fix for an oversight like this is fast.

For those interested, a cleansed version of the XML for the WebpageControl I am using is below.

              <Control Type=”WebpageControl” Label=”” LabelPosition=”Left” Name=”ReportStoplight”>
                  <WebpageControlOptions AllowScript=”false” ReloadOnParamChange=”true”>
                        <Link UrlRoot=”@ProcessGuidance” UrlPath=”reports/stoplight.aspx?S1={0}&amp;S2={1}”>
                          <Param Index=”0″ Value=”Namespace.StatusEarnedValue” Type=”Current” />
                          <Param Index=”1″ Value=”Namespace.StatusBudgetVariance” Type=”Current” />
                        </Link>
                 </ WebpageControlOptions>
              </Control>

I simplified this to just two parameters, but you get the idea.  If you’d like more information about using the WebPage Controls, have a look at these resources:

WebpageControlOptions http://msdn.microsoft.com/en-us/library/dd936135.aspx
Link and Param Elements http://msdn.microsoft.com/en-us/library/dd936107.aspx

Scrum for Team System (SFTS) Update Lags

The Scrum for Team System (SFTS) template uses a custom web service to do calculations and enforce transition rules for TFS work items.  This is really handy, but in TFS 2010 I’d noticed a lag between when a work item was saved and when it was actually caught by the listener.

Today, I ran across a MSDN blog entry by Chris Sidi that specifically addresses the issue.  Unlike TFS 2008 that issued Work Item change events immediately through the web service, TFS 2010 aggregates all of these to be processed every 2 minutes, helping performance in large enterprise implementations.

In his posting, Chris provides a Powershell Script that modifies the TF Registry allowing you to set this to a lower number, even 0.  Apparently this will be lowered in a future service pack to TFS, but for now, we’ll need to change the setting manually. I have taken this down to 10 seconds and everything seems to be responding much better.

Thanks Chris!