Awhile ago I posted about my attempts to upgrade TFS 2005 (Workgroup mode - not AD) to TFS 2008 Beta 2 and the ensuing "TFS220059" error messages during the installation. I worked with Microsoft, they figured out the problem and had me test a fix.
About two weeks ago, the fixes which allowed me to upgrade were publicly released (as mentioned in Buck's blog). Since then Brian Harry has posted a series of other patches for TFS/Team Explorer 2008 Beta 2.
Considering this is a beta product, Microsoft is being very responsive to supporting the product. Even if you're just watching to figure out how long to wait after release to adopt TFS 2008, this series of events should make you feel better about how well the product is being supported.
One of the complaints I've heard frequently as I travel and work with customers on implementing TFS and Visual Studio Team System is that they can't disable the policy override. That is, when a user checks files into Team Foundation Version Control and they have not met the policies set in the team project for check-in, they are prompted to override the policy. The dialog does require that they enter a comment before being allowed to override but will always allow the override if they enter the comment.
So the follow on question is, if I can't prevent an override, how do I at least report it? In TFS 2005 the required data isn't pushed to the reporting warehouse so creating such a report isn't necessarily easy. In TFS 2008, the policy override comment is pushed to the warehouse. Even if you write such a report, it won't necessarily give you the data you expect. For example, if a user checks in a file and overrides the policy and then later goes back and remedies the situation (e.g., associate a work item to the changeset after the check in), the report will still show the point in time that the override occurred - not the current status.
The easiest way to capture the override is to have TFS send an email when the override occurs. This is still only a point-in-time notification and not necessarily the current state, but that is expected from an email. There are four built-in alerts available using Team Explorer and a slightly more robust set of work item alerts if you use the Visual Studio Team System Web Access Power Tool. Unfortunately the policy override is not one of them. Instead you will have to create a custom subscription to the CheckinEvent using BISSUBSCRIBE or the Event Subscription Tool available from CodePlex.
I recommend using the Event Subscription Tool because it is more user friendly, provides the ability to easily manage custom subscriptions, and does not require login access to the server. If you need to script it, BISSUBSCRIBE might be a better choice.
Now this information is not new or revolutionary. The primary reason I'm blogging it is that ever time a client asks I have to look up the syntax for the custom query. Although the Event Subscription Tool provides some help related to work item events, it does almost nothing for other events such as the CheckinEvent. In the future when I'm asked, the answer will be "check my blog!"
Here is the general syntax that you can use; swap our your team project or delete that portion of the query as appropriate:
"TeamProject" = 'MyTeamProject' AND "PolicyOverrideComment" <> ''
And for those of you who prefer a visual, here is the syntax as shown in the Event Subscription Tool:
Although I don't typically use them, here are some additional filters that you may be able to use for the checkin event:
| Field | Comments |
| AllChangesIncluded | true or false |
| Subscriber | Domain qualified user account (“domain\user”) |
| Title | Example: Calc Changeset 124 |
| ContentTitle | Example: Changeset 124 |
| Owner | Domain qualified user account |
| Committer | Domain qualified user account |
| Number | Changeset number (e.g., 124) |
| CreationDate | Example: 5/31/2006 5:49:18 PM |
| Comment | User comment from the checkin. |
| TimeZone | Example: Central Daylight Time |
| TimeZoneOffset | Example: -05:00:00 |
| TeamProject | Team project name, as shown in the example. |
| PolicyOverrideComment | Checkin override comment, as shown in the example. Note that this will always be populated if there was an override and always be empty if there wasn’t an override. |
There are a few other things that we can pull from the checkin event and possibly use for custom alerts, but those will need to be part of another post...
Enjoy!