In the team Explorer, Change Default State value of a selected Work Item to "Associate" instead of "Resolve" on Check In
In the team Explorer, Change Default State value of a selected Work Item to Associate instead of Resolve on Check In. In VS 2012, our team often closed the work item because Team explorer Automatically chooses Resolve instead of Associate in team Explorer. Its really Annoying. In most scenarios, the developer is going to associate lots of check ins for a task. they resolve the task only once , when the task is completed. so its better to make a default value as an associate instead of Resolve. or At least given an option to choose an default value. Thanks.
We are using Team Foundation Service.
After I drag a work item to "Related Work Items" under "Pending Changes", the "Check-in Action" should default to "Associate", not "Resolve".
Furthermore, after I check in a changeset, the Work Items that were not set to "Resolve" should not be cleared from the "Related Work Items".
When you link your changeset to one or more workitems, the default check-in action is resolve. There are two options to change this setting:
- Remove the action in the transition in the work item type definition. This also removes the 'resolved' check-in action, so only Associate is available.
- Manually set the registery key ResolveAsDefaultCheckinAction
to false on the developer machine.
Can you provide a solution to set the default value to Associate without removing the resolved option, and to make it easy to change for a group of developers (i.e. not on the development machine).
John Rack commented
It defaults to Resolve because the work item you are checking in against is in its original state of "To Do" for example. You need to transition the work items state out of the original, then it will default to Associate.
Paul Coste commented
This should be fully configurable.
We should be able to 1) define what actions are available under different conditions and what those actions will do, as part of the workflow; it should not just be limited to Associate or Resolve; there may be cases in certain workflows that other actions such as Close or Reopen may make sense; it should be up to the implementation team to determine this. 2) there should be an ability to define precedence of the order of actions, with the top one being used as a default; this would handle the case where multiple actions are defined and in different circumstances either one might be a default action when they are mutually exclusive, but when they appear together, one of them should take precedence.
Stephen Martindale commented
This should be a supported feature in the Visual Studio options dialog, a registry hack should *not* be required for such an elementary end essential preference. Secondly, the registry hack does not work in Visual Studio 2012, even if you run `devenv /setup' afterwards.
Kurt Marr commented
definately. It is not helpful to have it set to 'Close'
Robert Wallace commented
I have tfs 2012 with vs 2013 on a windows 8.1 machine. Tom Zschaage's regedit fix work (path is "12.0" and not 10.0"
Louis Tourtellotte commented
Tom Zschaage's regedit fix works for 2013.
V Grimes commented
When is MS going to fix this?? VERY annoying!
Jens Neubauer commented
We recently started working more heavily with work items, and this behavior is incredibly annoying. I would give it more than 3 votes if I could
Joberto Diniz commented
Is this going to be fixed?
I think the best solution is to add option to settings that can switch this
The default here needs to change to "associate". As Gregg mentions, most tasks are only resolved after multiple check-ins. On top of that if the overall project is using an automated server build, test & deploy mechanism you can't possibly say the item is resolved at check-in as you need to see the unit tests, deploy & UI tests have passed on the build server before you can say the work item is complete.
It's a painful UI experience because the work item status is used in most of the work item views & the my work mechanism. Once the work item is transitioned to resolved(closed) it disappears from these lists so you have to go and find it again to set it back to in progress. I've lost count of the number of times I've had to do this.
Brian List commented
This problem does not bode well for us being able to make the switch to VS2012.
Gregg B. Jensen commented
I agree, this should always default to Associate and not resolve. Most developers check in multiple times per task or story. It should be a conscious choice to resolve the item.
Tom Zschaage commented
There is already a registry key available to set the default. However it is not used in VS 2012
Stephen John Anderson commented
It's also fairly common for workflows to require additional fields to be set on a work item before it can be resolved; if you commit without entering required values, VS2012 fails to associate the changeset.
Rory Primrose commented
FYI, The registry hack does not work for TFS 2012.