It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Why can't I make changes on my DRAFT workflow?

JIRA, you're killing me!

While trying to add transitions to workflows, I keep getting error messages like:

"You cannot perform this operation on a draft workflow." (while trying to add a new transition)

"You are editing a draft workflow.  The step "[stepname]" has no outgoing transitions in the Active workflow, so you cannot add any outgoing transitions in the Draft workflow." (while trying to publish a draft workflow - and adding an outgoing transition is PRECISELY what I was trying to do!)

This makes no sense.  It's like it's asking me to change an ACTIVE workflow, which I can only do while in DRAFT, then it fails.  I can't see any way around this.  Is this a bug?  If so, when can a fix be expected??

9 answers

8 votes

There's a long-standing howling bug in the workflow editor in that it can only add a transition to steps that already have outgoing transitions.

We've been waiting for a fix since the workflow editor got "draft" mode, and I'm afraid it seems to be a very low priority for Atlassian.  So there's no fix forthcoming any time soon, and we can't plan on one being released ever.

I'm afraid you will need to work on a copy and migrate.

My heart is breaking

Like # people like this

This is seriously flawed - this issue makes it stupidly difficult to add a transition.

Atlasssian seriously, c'mon!!!!

This popped up for me when a user placed an Issue in our new specified "Done" status. So I thought to be smart and edit the workflow with a Transition to the start of the workflow, but this of course didn't work and gave the aformentioned error. This bug is very annoying and unfriendly towards new users, especially when I have to browse forum after forum to find out other people have the same issue as I have.

It is annoying, but it's a minor bug, with a work-around and it only affects a small handful of users.  So it's a low priority for Atlassian.

Plus, it might be going away if the latest direction for automation is followed up in full.

Like Simon Boda likes this

> only affects a small handful of users

 

you mean like anyone ever wanting to change the default diagram?

Like # people like this

No, we're not talking about that (and that isn't a problem anyway), it's the "can't add transition in draft unless there's one there already" problem.  

Like Simon Boda likes this

Yup, this very error happened to me when I tried to add a new transition to a default diagram where all states are like

[ State ] <--- [ All ]

I had to make a copy of that diagram, make the changes and do a migration. That's why I found this thread and why I replied in a first place.

So could there be any other reason for the error occuring to me? Because if not, this error can affect more than _small handful_ of users, right?

Like Jean Gordon likes this

Nope, no other reason.  It's a design flaw.

It only affects administrators, and only those who have inherited poorly designed workflows built by inexperienced admins.  That's probably less than a "small handful" of users to be honest, or at least should be, as the biggest mistake people make with Jira is "too many admins".

I did not set up the JIRA, you are right. Yet I assume that the only

[ State ] <--- [ All ]

diagram is the most basic / default. In most small projects, it's what you need. How is it poorly designed? And why judging the design matters if it is a bug?

It's poorly designed because the design creates this problem.

'Poorly Designed' workflow editor... or workflow

Our workflow as designed to allow teams to create their own workflows using 'drop and drag' on their Agile board.  Every status only has an inbound 'All' transition.  No mention anywhere of this restriction/bug until its too late.

Ie - some teams want to work only with 'ToDo' and 'Done' then they can. And the same flexibility for teams that want to work with a waterfall like SDLC, and they can do that without needing any assistance from a JIRA admin

So how can I fix this without releasing a new workflow that will touch 400k issues and throw our dev stats into the can?

Like # people like this

You don't - please see the conversation above!

Like Richard Lucas likes this

Thanks Nic,

Its bit of a bind (or other words that begin with 'b') to hit this obstacle as we have painted ourselves into a corner with our management reporting that is based on last update date...  doh!

Any idea if this has been fixed in newer versions (7.13 or 8) of JIRA?

Anyway, with your excellent ScriptRunner, we were able to come up with an even better solution to create a 'Corrections Needed' scripted field that could be used in a condition on the existing transitions.

Still broken in 8.1

@Nic Brough {Adaptavist} You say there's a workaround. Please, PLEASE tell us of this workaround.

EDIT: nvm, I see it below, trying now...

So when I develop a workflow I need to know every reversion  state ahead of time?   I allowed many states to transition to Done, via a cancel transition.   The we realized that Canceled needed to revert back to the previous state, but ONLY the previous state and only under certain conditions.  Discovering this is not POOR design, its discovery process ex post facto.

No, you just need to make sure each status has at least one transition out when you create a new workflow.  You don't need to have the final design, just enough to be able to edit it later.

Hello Friends,

You cannot edit the workflow because it is "Active", means it is already assigned to a Project.
(even if workflow is Active you can make little changes, like renaming Status/Transition)

Here is the Solution (it worked for me every time)

- Go to Edit the workflow
- Try to publish (without change) and Create a backup copy there

- Go to JIRA Settings -> Issues -> Workflows
- Go to Inactive Workflow section and try to Edit the workflow that you just created as a backup
- Make the changes and keep the window as it is (you may not find the option to save anything there)

- In a separate window, go to Project Settings -> Workflows
- Go to Add Workflow and select the same Workflow that you just edited in separate window
- Click few Next buttons, if there is no new Status it will probably not ask to match the status between Old and new workflows
- Publish it and your are Done (Close the other window where you still opened that Workflow in Edit mode)

 

Hopefully it will work for you.

Yes, that's the long version of what we've already said.

Thanks for this thorough explanation - it did the trick!

Like Pankaj Verma likes this

Thanks this saved my day!

Sir, thank you, Sir!

Hi,

I'm trying to follow these steps but I can't create the new Workflow with the same name. 

Any ideas?

Create the workflow with a different name, then rename it after you've removed or renamed the old one.

To Atlassian: If you are not going to fix this right away, at least, please make that message clear, admit that this is currently a bug and point to a clearly written step to get around it - like editing it in disabled mode.  The lengthy information on the page that you point to really isn't very helpful either. We need good user experience, we all know things will have bugs especially this is a coding tool anyway, so no coverups, be transparent and be helpful.

There is a workaround. Create a copy of your workflow in global ISSUE menu

Make necessary changes 

Switch workflow in your project to the new one

remove the old one to not create a mess of workflows in Jira)

This is awesome suggestion, Katerina!!

I also facing same issue in JIRA really its Kill my Mind

Not an answer but a comment:

I'm in the evaluation process for Atlassian products and encountered this issue.

This is definitely a big -, not only as a serious flaw but also the response that a workaround is available is too lazy. The feedback on the error is also terrible:

It took me way too long before even considering that something so trivial could be a bug that needs a workaround.

Overall I'm still impressed with Jira, and competing products have their own bugs, so this won't be the dealbreaker, just a considerable negative point.

Come on, just replacing an old test tool that were not covering our needs and fell over this shitty problem. Dont have time to bother with work arounds, all resolved issues will have done resolution set automatically by use of post function until you fix this.

Except from that this tool seems awesome!

This is annoying. 
What I've done is start to use Workflow Schemes at project levels, even if they're all just joining to one "Standard Workflow" scheme that points to a single "Standard Workflow" workflow. 

That way if i need to make a new copy of "standard workflow(3)" so i can tinker with transitions, I can change it at the scheme level and update all projects simultaneously. 

This is just silly.  And everyone saying "this is awesome!" for a solution to clone a workflow in order to achieve this basic functionality should rethink what they wrote. "This" is not awesome, any "workaround" sucks. We should just be able to edit it right inside the draft  and that's it.

<sigh>  No one is saying "this is awesome", everyone agrees this could be better.  Maybe you should try reading the conversation properly?

I read it properly enough. People are not happy, I get it.  But they are not unhappy enough for me, sorry, it's just me. "Awesome" and "workaround" shouldn't even be in the same sentence when it comes to this poor functionality.

The word "awesome" was used to say "thank you for suggesting a workaround", by one person, not "everyone". 

I was exaggerating. Sorry, I just get triggered every time I hear about this issue not being resolved properly. Obviously, that person is not at fault for thanking for a workaround and the person who provided the workaround IS awesome. 

I know, it annoys me too, it's a silly flaw.

There's a longer thread somewhere else on the same subject, with an explanation from an Atlassian which is a bit sketchy about how the mistake was made, but a lot of detail about why it's not going to be fixed.

Like Marcin Kwiecien likes this

We got our deliverables regardless of what Atlassian dictates. The awesome part is that with the help of others, we got out of this bind. We did not have to waste as much time and got it fixed, and we can move on.


Awefulness is that JIRA is a product to help us do the dev workflow thing. That's the core of it, and that very core of it does not work, and nothing is being done or taking super long time. The company that promotes Agile is not moving in that agile direction...

@Nic Brough {Adaptavist}As a Community Leader, can you provide a link to the "Official" long description on why this is not going to be fixed?   Is there an "Official" thread on this issue? 

I ask because in the community there seems to be a lot of "that's the way it is , deal with it," or "if you had experienced and well trained Workflow developers this wouldn't be an issue"   comments made by people that are in the know and these seem very condescending to those of us that have to work with this product every day without dedicated staff that knows all of these work-arounds.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Demo Den Ep. 7: New Jira Cloud Reports

Learn how to use two new reports for next-gen projects in Jira Cloud:  Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...

247 views 1 2
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you