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.
suresh2
shared this idea
We’re happy to let you know that we’ve added a feature to Visual Studio to allow users to choose whether or not the “Resolve” action is the default. You can find this setting under Tools > Options > Source Control.
This is available in VS 2015 CTP 6.
Matt Mitrik
TFS Program Manager
24 comments
-
I apologize, it's in VS 2015 CTP6. There is a checkbox for "Resolve associated work items on check-in".
-
Anonymous
commented
Did you mean VS2013 Update 5 or VS2015? I can't find it under Tools > Options > Source Control in VS 2013 Update 4. Maybe you could be a bit more precise where to find it or how the option is named.
-
suresh2
commented
VS 2013 we always had workaround using Registry key. The issue is with VS 2012 with no workaround and no Update coming and its looks like its going to be the issue never going to be fixed in VS 2012 and people will forget and move on to next versions. :-(
-
This is available in VS 2013 Update 4.
-
Karen
commented
I am sorry but i don't see this new option. In what version is it showing?
-
pszalapski
commented
Which version is this new in?
-
Yoyo
commented
For Visual studio 2013, modify the registry key works.
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Behavior]
"ResolveAsDefaultCheckinAction"="False" -
Carlos
commented
Are there any plans to fix this?
-
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?
-
Andrii commented
I think the best solution is to add option to settings that can switch this
-
Paul
commented
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.