As TeamCompanion traditionally sim-ships with new Team Foundation Server versions, the latest release from Microsoft was not an exception. We are proud to announce that our newest version 5.2 fully supports the Visual Studio 2013 and Team Foundation Server 2013 released on 13th November this month.
Together with features already released in v5.1 which supported Team Foundation Server 2013 Preview, TeamCompanion v5.2 brings you following features and improvements:
Support for TFS 2013
TeamCompanion rides together with you when upgrading to the newest TFS release. No matter if you are using TFS server or VS Online, your favorite client will be at your disposal.
Support for multiple work item views
Note: Contents of this topic entry were updated after the release of TeamCompanion 5.2 Update 1.
The definition of each work item type contains the view for the work item form. Built-in TFS clients (Visual Studio Team Explorer, Web Access) handle just the default view definition. TeamCompanion handles multiple work item type views, allowing you to define different views for different users, TFS or AD groups.
You can benefit from this feature in many ways. Generally speaking, each type of stakeholder on your project is interested in and uses different work item fields. By defining different views for different groups or individuals, you can adjust their insight in the work item database. In this way they can focus just on those work item fields they really need from their perspective.
The following pictures show the same work item of type Epic displayed using two different views. The top picture shows a simplified view comparing to the view shown on the bottom picture and it contains only a selection of work item fields.
Project administrators assign views to roles using a supplementary administrative tool (available as separate download for TFS 2012and TFS 2013). Role-based view mappings can be defined on three possible levels: per user, per TFS group or per AD group.
The following picture shows how three different mappings can be defined. Julia uses the custom view named “Custom View”, the TFS group Fabrikam Fiber Web Team uses the simplified version of this view named “Custom View Simplified”, while the AD group Users uses the third custom view named “Generic View”. In this example, Julia has full access to work item fields on a customized form, the team gets a simplified version of the same view, while other users get only the preview containing general purpose work item fields. Users that do not fall into any of the defined mappings always use the default work item view, the same used by default TFS clients.
Changes in role-based view mappings are saved on the server as part of team project settings and are retrieved by TeamCompanion when Outlook starts or when you connect to a new team project.
Multiple work item views or layouts are defined within work item type definitions. The following picture shows the rough structure of a work item type definition containing the default layout and three custom layouts used in the above example.
Support for project level management of TeamCompanion configuration options regarding conversion between Outlook and TFS objects
Previous TeamCompanion versions allowed you to define a single set of configuration options regarding conversion between Outlook and TFS objects. The same rules where then applied to all team projects you accessed using TeamCompanion.
In this version we have improved this feature and now we allow you to manage the same settings per team project, so that different team projects can use different settings. The Options dialog has been redesigned and it now contains a single tab named Project Settings, which contains all settings related to the conversion between Outlook and TFS objects (Send Work Item as Mail, Create WI from Mail, Create Task from a Work Item and v.v., Create Meeting Request, Create WI from RSS).
Conversion rules are now configurable for each work item type. This means that, for example, a mail created from a Product Backlog Item and from a Task can be formatted in different ways, according to business needs for each particular work item type.
By default, you get two sets of settings. The default one is named “All work item types” and is applied to all work items that do not have their own settings defined (this set can not be deleted). Additionally, we deliver a set for the work item type Bug. For example, the difference between these sets is visible when sending work items as emails. When sending a bug per email, the email body contains the contents of the ReproSteps work item field. When sending any other work item except a bug, the email body contains the contents of the Description work item field.
TeamCompanion supports two distinct cases:
Case 1: There is no project policy set and each user can manage his preferences locally. This is the default case after installation.
Case 2: Project settings are put in place in form of a project policy saved on the server. Only project administrators can manage project policy settings and they must explicitly save all changes to the policy on the server. In this case, policy settings are automatically distributed to all users after they restart Outlook. If users previously defined any local settings, these will be overwritten with policy settings without warning. Users without administrative privileges can only preview policy settings.
Support for backlog query changes introduced in TFS 2013
TeamCompanion stays always up to date with changes which Microsoft constantly introduces in its project management tools. This time we have implemented the recent change in Web Access so that our product backlog list now contains committed PBIs as well.
Various fixes and improvements
Thank you for your feedback. We fixed various bugs (e.g. creating work items from mails which contain embedded pictures) and improved particular features (e.g. highlighting of search results).