How can we improve Azure DevOps?

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.

396 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

suresh2 shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Anonymous commented  ·   ·  Flag as inappropriate

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

    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. :-(

  • Karen commented  ·   ·  Flag as inappropriate

    I am sorry but i don't see this new option. In what version is it showing?

  • Yoyo commented  ·   ·  Flag as inappropriate

    For Visual studio 2013, modify the registry key works.


  • John 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 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 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 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 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

  • Andrii commented  ·   ·  Flag as inappropriate

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

  • Paul 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.

← Previous 1

Feedback and Knowledge Base