There is no built-in command to achieve this.
You can turn off all e-mail alerts in the TFS Admin Console by unchecking the "Enable Email Alerts" checkbox.
Alternatively you could also remove disable SMTP settings via command line:
%ProgramFiles%\TFSConfig ConfigureMail /Enabled:False|True
(Special thanks to Jim Lamb, Microsoft, for making me aware of the command line, and Martin Kulov and Tiago Pascoal for the idea to just disable the SMTP settings.)
- 03/28/2011: Changed the command line parameters from using the SMTP settings (/FromEmailAddress:EmailAddress /SmtpHost:SMTPHostName) to just use "/Enabled:True|False" (Thanks to Rich Hundhausen for making me aware, Thanks to Jim again for providing the undocumented parameter).
In the Visual Studio Scrum 1.0 process template (and most likely in future process templates), Microsoft is using HTML fields with rich formatting for the work item description fields.
In VS Scrum 1.0…
- Product Backlog Items and Tasks are using Microsoft.VSTS.Common.DescriptionHtml.
- Bugs are using Microsoft.VSTS.TCM.ReproSteps instead.
You can customize your current process template and add a new HTML description today.
To move the data from your existing Description (Reference Name: System.Description) field to a new HTML-enabled field, you can use the TfsMoveDescription command line tool:
tfsmovedescriptions.exe /collection:<URI> /teamproject:<name> /workitemtype:<name> /newfield:<name>
The tool supports two scenarios:
- Copying from a text field to an HTML field
- Copying form an HTML field to an HTML field
- SourceField can be PlainText or HTML
- TargetField needs to be HTML.
Important optional parameters:
- If you run with /preview, it will actually list you’re the affected work item IDs.
- If you specify /copyifempty it will only do the copying if the target field is empty (otherwise it will skip that work item).
Download the tool from here:
Prerequisite: This tool requires Team Explorer to be installed.
You receive the error message:
Work item type is not valid. You must specify a valid work item type.
You need to import work item categories using witadmin like this:
importcategories /collection:http://server:8080/tfs/collection /p:Project /f:categories.xml
MSDN docs: http://msdn.microsoft.com/en-us/library/dd273721.aspx
You can extract the categories.xml from the Process Template definition.
(Thanks to Ruiz Yi from MSDN Subscriber Support for his post with the solution)
Customizing Work Item Types
Work Item Type Schema Reference
(Thanks to KathrynE)
Update (Aug 8th, 2011): How to get in IntelliSense when editing WITDs and where to download the XML schema is explained in this blog post by Allen Clark from Microsoft.
As announced here. From the description:
This template includes:
- Work Item Types
- Product Backlog Item
- Test Case
- Release Burndown
- Sprint Burndown
- Build Success Over Time
- Build Summary
- Test Case Readiness
- Test Plan Progress
- SharePoint Project Portal
Below are screenshots of the Sprint Burndown and Release Burndown reports included with the template.
(All images in this blog post: Copyright by Microsoft Corp.)
Team Foundation Server is easily customizable and equipped with a general purpose workflow or state machine. So you might ask yourself: why not put a non-development or rather related process in TFS instead of using separate software.
Showcase #1: Lead Management
Since here at AIT TeamSystemPro Team we are TFS consultants we decided to not use a commercial CRM tool for managing our leads but rather customize a team project in TFS for this matter.
Here are a few impressions of the experience:
Work Item queries:
Work Item layout:
in Outlook (via TeamCompanion)
The pretty simple workflow behind it:
Showcase #2: Customer Support
Needless to say that the TFS support that we offer is tracked using work items as well:
Showcase #3: List of managed TFS instances
Every TFS instance that we manage has a corresponding record:
Do you have an interesting idea or have you used your TFS to support a non-dev related process? Feel free to leave me a comment or use the contact link – thanks!
If you want to start small with your team project you might consider the “Basic Process Template” instead of the built-in MSF Agile and MSF CMMI process templates. It can find on MSDN. From the description:
The basic process template includes:
- one work item type: bug,
- three queries: AllWorkItems, MyWorkItems, and MyWorkItemsAllTeamProjects,
- a basic Windows SharePoint Services team portal (created from the default site template),
- and a SQL Server 2005 Reporting Services site that has the following reports on it: Builds, Bug Rates, Quality Indicators, Tests Failing Without Active Bugs and Load Test Summary.
Use this process template as a basic starting point and an alternative to the MSF for Agile Software Development or the MSF for CMMI Process Improvement templates.
Step 1: Upload the process template to your TFS
Step 2: Create a new team project (using the new process template)
Step 3: Discover what’s been created
Beginning with TFS 2008 SP1 you can specify that only the necessary part of the Work Item meta data will be transferred to the client caches, e.g. not the meta data for project you have no permission on. This is not done by default.
You can read all the glory details in Martin Woodward’s blog. Short excerpt:
Enabling WIT Meta-data filtering
Now that we have been through all the gory details, let’s finally see how to switch on the feature.
In the appSettings section of the %ProgramFiles%\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\WorkItemTracking\web.config file add the following keys
1: <add key ="filterClientMetadata" value="true"/>
2: <add key ="excludedUserAgents" value="WebAccess:w3wp:witfields:witimport:witexport:witadmin"/>
The filterClientMetadata switch determines whether to filter client metadata based on the calling user’s access rights (true) or not (false). If not provided the setting will default to false.
The excludedUserAgents switch is a colon delimitated list of strings that may appear in the requested clients HttpRequest UserAgent header. You can take a look at your IIS logs or your TFS Activity logs to determine what user agents are used, but a handy feature of the TFS .NET API is that the executable name using the API is recorded in the user agent string, meaning that you can easily find your specific utility and exclude it if necessary. As far as I am aware, the only publically accessible application that makes use of shared meta-data is Team System Web Access, so we put “WebAccess” in our excluded user agents setting. We also put in the names of the utilities in Team System that need to see all the metadata to report back correct information to the TFS administrators.