I suggest you ...

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.

796 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    suresh2suresh2 shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Mike LaBrotMike LaBrot shared a merged idea: Team Foundation Service: Related Work Item: Default to Associate  ·   · 
    Koen MatonKoen Maton shared a merged idea: Make changing default check-in action easy  ·   · 

    18 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • YoyoYoyo commented  ·   ·  Flag as inappropriate

        For Visual studio 2013, modify the registry key works.

        [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Behavior]
        "ResolveAsDefaultCheckinAction"="False"

      • John RackJohn Rack commented  ·   ·  Flag as inappropriate

        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 CostePaul Coste commented  ·   ·  Flag as inappropriate

        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 MartindaleStephen Martindale commented  ·   ·  Flag as inappropriate

        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.

      • Robert WallaceRobert Wallace commented  ·   ·  Flag as inappropriate

        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"

      • Jens NeubauerJens Neubauer commented  ·   ·  Flag as inappropriate

        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

      • AndriiAndrii commented  ·   ·  Flag as inappropriate

        I think the best solution is to add option to settings that can switch this

      • PaulPaul commented  ·   ·  Flag as inappropriate

        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.

      • Gregg B. JensenGregg B. Jensen commented  ·   ·  Flag as inappropriate

        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 ZschaageTom Zschaage commented  ·   ·  Flag as inappropriate

        There is already a registry key available to set the default. However it is not used in VS 2012
        [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Behavior]
        "ResolveAsDefaultCheckinAction"="False"

      • Stephen John AndersonStephen John Anderson commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base