4

I've read all the MSDN docs, but cannot find a way to edit the work item transitions in Azure DevOps Service (VSTS online).

I'm trying to:

  1. Add a custom Reason to a State of a work item. (e.g. "resolved", "won't fix")
  2. See/edit all the existing rules about how states transition.
Amittai Shapira
  • 3,749
  • 1
  • 30
  • 54
Nik
  • 2,718
  • 23
  • 34

6 Answers6

3

This is possible if you are on the Hosted XML Process model in VSTS. Hosted XML process model concept - VSTS

When are you on the Hosted XML Process model you ask?? Well after lots of reading I found the following note on the page explaining Hosted XML customization which states

Feature availability: Import process supports the Hosted XML process model which allows you to manage customizations through updating select XML definition files of a process template. This feature is only available for accounts that have been migrated to VSTS using the TFS Database Import Service.

But since I didn't import my VSTS I'm on the Inheritance Process model. Which does NOT currently support this feature as confirmed here in comments

@RohanDaniel @ehofman@MSFT @DevMarTechOps You are correct. Advanced workflow management, which includes restricting transitions and customizing the reasons of a transition is not yet possible in the Inheritance model. It is on our backlog to add though.

Also, if you indeed used a high fidelity migration tool and you have a Hosted XML process model, you are stuck on it. You cannot move to the inheritance model as seen in this link.

In summary then. On the Inheritance Process model in VSTS this is not a feature that is available currently but is on the backlog as confirmed by MS. However it is not planned for delivery in the next few months and a year or more from now is more likely.

In my case I also had to add addition fields and a new state on the BUG WIT (Work Item Type). This was accomplished on VSTS by customizing a process which is done by inheriting from one of the standard processes ( Agile, CMMI, Scrum ) which you can then customize.

You can add customized rules to a WIT and you can base a rule on changes to the state.... however the rules seems too limited to restrict transitions and the options to set fields doesn't have the "Reason" field available.

Rohan
  • 578
  • 8
  • 12
2

In fact, I came up with a solution! Which I admit is not clean as I would like, but it works.

I created three new fields: "Rules error" (Text single line), "Rules broken" (Text single line) and "Rules activated" (Boolean).

"Rules error" I put it on the main tab so I can see the error and the two others I created a tab named "Useless" in which I put them.

Now, add a rule making the reset:

  • Name: Reset rules
  • Condition: The value of equals ==> "Rules activated" ==> true
  • Action: Clear the value ==> "Rules error"

And then one rule per not wanted transition of states:

  • Name: State change - Approved to Deployed QA
  • Condition: A work item state changes from ==> Approved ==> Deployed QA
  • Action: Make required ==> "Rules broken"
  • Action: Set the value of ==> "Rules activated" ==> true
  • Action: Set the value of ==> "Rules error" ==> "Can't change from Approved to Deployed QA"

I know, entering something in the field "Rules broken" breaks this enforcement, but as this functionality doesn't exist, it is the only way I came up with when you don't have access to Hosted XML.

Master DJon
  • 1,899
  • 2
  • 19
  • 30
1

Neither of those things appear to be possible at the moment.

The VSTS process customisation is very different to TFS and is still evolving. #1 seems like something that might be added in a future update. But #2 doesn't seem like it would appear, as Microsoft have relaxed most of the transition rules on all the templates on VSTS by default.

DaveShaw
  • 52,123
  • 16
  • 112
  • 141
1

This is currently not possible when using inheritance process.

You can vote for this feature request in the community: Allow specifying state transitions when using inheritance process

Bernard Vander Beken
  • 4,848
  • 5
  • 54
  • 76
0

It's possible by creating our own custom extensions and creating some rules that disable state changes from one state to another state

I have implemented this for my org but haven't published it online..will do it soon

Shan
  • 2,822
  • 9
  • 40
  • 61
0

Here is a workaround for denying any users who are not a member of group "HighLevelManagement" to change state from Approved to Committed for PBI:

  1. Create a new Field Called "Unlocked".
  2. create a new rule to "Hide the Field" when the user is not part of "HighLevelManagement" as below

enter image description here

  1. Create a new rule with action "Make Read Only" set to "State" when Unlocked is False and workitem change from Approved to Commited as below:

enter image description here

Now whenever a user from HighLevelManagement wants to change state from Approved to Committed he simply tick Unlocked change state and then tick back Unlocked, that way anyone from outside HighLevelManagement will be restricted to change state from Approved to Committed.

Stacker
  • 8,157
  • 18
  • 73
  • 135