I'm having trouble adding a new transition

[Yossi Geretz]

Here is my workflow:

The relevant transition here is Not Fixed. This is the transition from Resolved to Reopened. I use this when a defect is reported by the developer to have been fixed, but then fails internal testing.

If the defect passes internal testing, I'll deploy it to production and mark the ticket as Deployed to Prod. However, it is quite possible that the defect may re-appear in production if the fix (and testing) was not as comprehensive as it should have been. In this case I'd like to implement the same transition in order to reopen the ticket.

So here's the workflow I'm trying to implement. You can see it at the bottom of the diagram, I am reusing the Not Fixed transition to go from Deployed to Prod back to the Reopened state.

Great - so everything is looking good and now I try to publish the draft. I have no idea what this means or how to work around this.

 

You are editing a draft workflow. The step 'Deployed to Prod' has no outgoing transitions in the Active workflow, so you cannot add any outgoing transitions in the Draft workflow.

How do I get past this? Thanks!

[Nic Brough -Adaptavist- · Accepted solution]

This is due to a howling bug in the "draft workflow" function. 

It is annoying, and it has been reported many times to Atlassian, but they're not going to fix it because:

• The coding for it is not trivial, it's not like appending a line of text to a document, a line to a spreadsheet or a new column or table to a database, there's a whole load of structural work that would need to be done to the draft editor.  Borderline "rewrite from scratch"
• The long term plan is for the workflow editors (main and draft) are going away - replaced by different ways to do workflows
• The bug is limited in impact too:
  • It is only steps that have no exit transition
  • It has a workaround
  • It can be avoided
  • It only affects administrator users (and within that sub-set, only those of us who don't know to avoid it, or inherit systems from other admins who didn't know)

All of those reasons push it way down their list of priorities.

To avoid it:  Train your admins that when they create or edit a workflow, remember to always have an outgoing transition on every step.  If you genuinely need a dead-end status that cannot be moved out of, create a transition back to any other step and stick a very limited conditions on it (like "must be a jira administrator" - that works for most places as they'll only have 3 or 4 and they probably won't have any reason to use it)

To work around it when you've run into it:

• Make a copy of the workflow affected.  This will create an "inactive" copy
• Edit the copy - you will be able to add the outgoing transitions to this, as the main editor does not have this bug (and remember the "avoid" - leave no step without outgoing transitions)
• Change the workflow schemes that are using the old workflow, swapping it for the new copy - assuming steps have not changed, the consequent migration will be trivial

[Yossi Geretz · Accepted solution]

Ugh - reading all the other posts on exactly this issue. Annoying. What I'm doing must be one of the most popular use-cases in the universe. I'm taking an existing workflow and extending it.

Why should ADDING a new transition be prohibited? This should be an operation which is completely backward compatible! It's not like I'm removing something which already exists in prior tickets which used the workflow.

Imagine where relational databases would be today if you weren't allowed to add a new table to an active database. Or add a new column to an active table. Or add a new constraint to an active column. (Like I said - when you generalize, it's one of the most popular use-cases in the universe.)

:-(