You cannot perform this operation on a draft workflow

[itay keller]

Hi.

As a JIRA administrator, I have several times edited and updated the workflow that our projects are using.

Today, when trying to edit the workflow and adding new transitions from "backlog" to "open" I'm getting the following error:

You cannot perform this operation on a draft workflow. More Information.

(where "more information" leads to the confluence page of editing workflows)

I don't understand what I'm doing wrong as it is clear that I'm working on a draft workflow that I will need to publish later on.

Thanks

[Marc Turner]

Ahh so to correct the default service desk workflow and add a single transition I have to create a whole new workflow, assign all existing issues to it? That is ridiculous. 

[Clive Brett]

the time required to research and get around this is crazy. I like the modular approach of jira, but this is nuts and very frustrating.

[David Hazeel]

Thank you for putting this here - it saved me a lot of time.

[Brian Pohuski]

I will show the monetary importance of this bug by using a very simple and real user journey map in the hope that Atlassian better understand the problem and prioritize it higher in their own product roadmap:

• Stakeholder is shown all the customization options and Jira's powerful abilities to customize
• Stakeholder decides to start a trial with Jira
• Stakeholder starts a new project in Jira
• Stakeholder tries to add a single status & transition to the default workflow, then save.
• Denied. "You cannot perform this operation on a draft workflow. {More Information}"
• Stakeholder looks at {More Information} link in error message.
• {More Information} link is not as helpful as the other link that should have been used, as Stakeholder spends a few minutes reading about workflows.
• Stakeholder reads: "When you edit an active workflow, JIRA first creates a draft of it, that you can then modify as you see fit," and glances over the information contained in the buried show/hide link that follows {Editing limitations...}.
• Stakeholder searches the web for a solution to this seemingly basic customization and finds this forum and is dismayed that this little problem is taking a long time. And starts to reconsider this product he/she is wrestling with.
• After reading the forum from users, the Stakeholder finally finds the workaround solution!
• Stakeholder then navigates to workflows, duplicates the current (default) workflow, changes the name of the duplicated workflow (but can't use the default name since it is the active one), adds the status and names it, adds the transition and names it, navigates to the workflow scheme, changes the workflow in the scheme, navigates back to workflows, then finally deletes the default workflow.
• Stakeholder sits back in his/her chair and imagines the nightmare of
  • A. doing that again for multiple projects
  • B. teaching others this very basic and essential customization that turned out to be a complete headache
  • remembering how to do the 9-step workaround to this bug after a couple months
• Stakeholder decides to not go through with Atlassian and does not spend money

[Bill H]

It is legit insane that this issue still exists. Want to add a Reopen status to a brand new project? Too bad! You can't transition from Published for some reason. How did nobody not notice and then fix this years ago?

Or at least allow you to set up the workflow as part of the project create process.

The new, incredibly obtuse interface where you hide everything doesn't help matters. 

[Mad Octopus]

That is EXACTLY what just happened to me. I was investigating if I'm going to use Jira for one of my projects, started trial, tried to set up the workflow and realized that it's too much efforts in fact. Not going to pay Atlassian after the trial sorry. This (and a number of other ridiculous issues like no way to put your own url for the cloud version or ridiculously high system requirements for the server version) is a total game stopper for me.

[Farid Bonawiede]

I thought the "draft" feature was intended for this use case. Thanks for the workaround! And thank you Atlassian, for nothing... =)

[Christian Czaia _Decadis AG_]

Hi,

in your case you're running into a known issue. You can't add outgoing transitions to final statuses.

If you want to work your way around this: 

1. Create new workflow as a copy (that way it will be inactive)
2. Add in all the transitions you need
3. Associate the workflow with your scheme and the issue types again to activate it
4. Run through the wizard
5. Done

Another thing you can't do on active workflows (drafts) is to delete statuses

[Daniel Sedlacek]

What you mean by "final statuses"? I have just created fresh copy of JIRA and I can not connect anything to the TO DO status. How is it final? How do I unfinal it?

Most importantly, why is the error message so unhelpful?

[Daniel Sedlacek]

Why? 

Why such arbitrary limitation?

Why is the error message so unhelpful?

[Enrico Foschi]

A known issue since Jul 2015 that apparently is still in the system. Considering the price tag you guys put on your products, I'd expect some of the basic issues (e.g. setting up a new workflow or changing the existing one) to be flawless.

[Graciela Jimenez]

Thank you Christian Czaia, your comment helped me

[Attila Zs]

@Enrico Foschi I agree. The more I bump into some ridiculous issues in managing Jira/Confluence, the more I realize how unprofessional Atlassian is.

[Brian Begy]

I'm an admin.  Why can't I add an outgoing transition to a draft?  What are you protecting me from?  

[Marc Moroz]

Please fix.  If this is working as expected then please round up the people who designed this and the people who approved that design, put them in a room with a door, close that door, lock it, and never go back.

[Nic Brough -Adaptavist-]

It's on the list, but it's way way down the priorities from what I hear.

[Sana Khan]

Can we please expedite the developer/designer round up process, its urgently required that these people are in that aforementioned room.

[Nic Brough -Adaptavist-]

I think you should take a look at how prioritisation works.  This problem affects two types of people - inexperienced admins who have not seen it before, and experienced admins who are cleaning up after others.

On top of "only a few people affected", there is a manual fix.  Less than ideal, it's a bit slow for the few affected, but it works, there's no damage done to data, but it's easy to fix.

That autmatically makes the problem not at all "urgent" - a fraction of users are affected, the problem is easily fixed, and even easier to prevent.  The only real problems are that 1) it's a bit silly that we have to do it and 2) it takes a bit longer than we should have to take to fix it.

[Marc Moroz]

When you have to do this across dozens of projects, you don't care that it only affects a few users.  You're right that it's avoidable.  The funny thing is that "Experienced Admin" in this context means someone that has learned through unnecessary trial and error where Jira doesn't do what it should do.  If Jira was an airplane, and "Experience Jira Pilot" would just know that the toilets on board don't flush.  It only affects the few people that need to use it and is not at all urgent... unless you need the bathroom."

[Nic Brough -Adaptavist-]

I don't think that's a good analogy - it might be better to say "the pilot's toilet doesn't flush, so they have to walk a bit further to use one"

[Marc Moroz]

You have a point.  A better analogy is that you if Jira was a yard care system, you would reasonably expect having irrigation with time/date settings.  You, the head gardener, are mildly inconvenienced by having to water everything by hand while your customers wonder why so many of their seemingly simple requests take so long to fulfill.  They don't necessarily see or care that you're watering everything by hand.

Another analogy is that this problem is only one papercut.  Seemingly minor.  But they add up.  Boy, do they add up. Especially for the people handling the paper.

Another analogy is that Jira is a movie.  It has glaring plot holes and it leaves many of its viewers feeling dissatisfied.  And along comes someone closely affiliated with the movie, let's call him Nic, to tell the viewers that their issues with the movie are minor.  They just don't get it.

[Fredrik Wallgren]

This horrible bug is still present, please fix it. 

[Max Sikström]

Yep... appearently, and it's over 2 years...

For me it's not worth adding the "Undo review" transition from "Done" to "In review", so we have to live with an out-of-date-workflow.

The workflow is shared by 5 projects, so it will be quite some work to disable the workflow and reeneble it again...

[David Holman]

Imagine my pain trying to update a shared workflow across 12 projects 😥

[Victor Vucicevich]

Unacceptable that this is still a bug.

[Nic Brough -Adaptavist-]

It's unacceptable for someone to assume that their one bug is more important than the other bugs and improvements the rest of the users want fixed - ones that don't have work-arounds or will make very large improvements for lots of users rather than just an admin.

Please don't make judgement calls like that - it's unfair and demanding, without being useful.  I can point at hundreds of things in Atlassian software that are far more important to me than this one, but our opinions as end-users have the same weight.

[Stacy Story]

I also find it a turn off to adding content to this community when the "community champions" are adversarial and edit messages several times in the middle of the night to generate lots of email spam causing users to unwatch message threads so things continue to get ignored.

[Joe Pitt]

Technically it isn't a 'bug'. It was designed that way. A bug is something that doesn't meet requirements. In this case it doesn't meet what some people want.

Workflows often span multiple projects and they didn't want certain things to be allowed because it may break the workflow. Creating a new one so you can go back to the old provides protection. I've been working in IT since 1983 and people are very bad about backing things up. 

[Nic Brough -Adaptavist-]

I don't think I was any more adversarial than someone yelling "unacceptable" instead of giving a reasoned argument as to why this one bug with a work-around is more important than the needs of others.  The edits were because I was being grumpy, because I don't like being told my opinion is worthless.

As for the edits - it's my morning here.  I can't stop you getting emails in the middle of the night if you've subscribed, sorry.  Email batching and being able to get finer-grained control of the mail is something that comes up with the community leads regularly, and is something that we'd like to improve.

[Bill H]

Nic, nobody is saying that this is the most important bug for atlassian to fix, that was something you made up and then got mad about....

Perhaps Atlassian needs to reevaluate their 'community champions' if they can't understand the frustrations of the community. People find this page after hours of trying to figure out why this issue with basic functionality exists and how to work around it. It is understandable that they will be frustrated after learning that people complained about it nearly THREE years ago.

[Victor Vucicevich]

This sort response by a community champion is what I see for nearly all bugs/features such as this and its really making me unsure as to who this support community is for -- users of Jira or people paid by Atlassian to get mad whenever someone has a suggestion or request. 

Right now, I am attempting to to edit a workflow. Its a small team of 5 people on one of our boards, and they had a request of the change of workflow. It was a simple ask. The concept in my own mind was simple. Even navigating to the page to do what I wanted to do was three clicks total. It was one click and drag to do it. 

What I wanted to do was clear and easy both in my mind and within Jira.

However, Jira decided that this clear concept cannot be done. But why? 

There is an endless and needless attempt by Jira to protect its users from making mistakes. But in this exact instance, it wasn't a mistake.  

There are even simple ways to handle this situation:

1. Warn people heavily about the action they are going to make (you know, explain to me why I can't do this? Let me acknowledge that I can do it?)
2. _Automatically_ create a backup when users take this action (If its such a scary thing then protect me for me. If it breaks something the backup is there no matter what). 
3. As an admin me an option that allows my workflow managers to take this action. 

But the crux of this problem is that its been here for three years. Three years. It is entirely fair to call this issue remaining unhandled and unanswered unacceptable. What makes it further ridiculous is that instead of offering up actual solutions or reasoning to this, the wonderful community champion Nic Brough has flown in to inform us that he is offended on Jira's behalf that people will genuinely look elsewhere at tools due to this bug. 

The simplicity of what I am trying to do is the same as creating a subtask on an issue. Its a single click and drag. But we're not allowed to do it. And there has not been a single explanation as to why.

Given the absolute simplicity of the overall problem its especially frustrating. 

[Nic Brough -Adaptavist-]

There are requests and bugs in Atlassian software that are

• A lot older. 
• Affect a lot more people
• Do not have workarounds

And are hence far more important than your opinion.

3 years is not unusual, and simply reflects that the opinion of the users and product managers is that there are lots of other things that are more important and more "unacceptable".   Jira 7.6 finally implemented something that MCB reported 15 years earlier.  15.

By yelling "unacceptable", you're venting, not contributing.  Have you come up with any other workarounds than simply copying and editing?  Written an add-on to fix it?  Contacted your TAM if you have one?  Voted on the issue(s) the record the issues in JaC?

[Victor Vucicevich]

Its alright Nic I'll just wait until 2030 to get an explanation for this one I guess. 

[Nic Brough -Adaptavist-]

Yeah, we might have to.  I know it's frustrating, but my point is not that it doesn't need fixing, just that there are other more important things to do.

[James Gould]

Well Nic it's at least 3 years old, if not older as you can see from here: https://jira.atlassian.com/browse/JRASERVER-47626

Either way bickering on this thread doesn't push anything along. 

[Nic Brough -Adaptavist-]

Indeed it does not, that's why I try to explain what is happening when people bicker about it 

[Christopher Watson]

Did......did one of Atlassians' community liaisons really just try to rebuke their communities feedback with:

"You think three years is bad? We're still sorting issues from fifteen years ago."

I understand the 'must prioritise' argument, but Atlassian is a global company that owns buildings. What, is their development team three unpaid interns in a regional office basement? How the hell does a barely functional kanban board program require fifteen years of active development and still not allow editing workflows.

[Nic Brough -Adaptavist-]

I'm not a "community liason" and it's not a rebuke.  It was a comment that was trying to re-iterate a point that had been repeatedly ignored.

Kanban boards are not 15 years old, and haven't been owned by Atlassian for anywhere near as long as that.  They're not "barely functional" - millions of people are using them very effectively.  And they do allow editing workflows (which aren't part of boards anyway).  The bug here is that there are a couple of things that the editor won't let you do with active workflows that are annoying when you run into them, and the few people affected quickly learn to not put themselves in a position where they have to deal with them again.

[Christopher Watson]

@Nic Brough -Adaptavist- you have both "Adaptavist" and "Community Champion" in your title and have been all over this thread, you're certainly representing Atlassian on some front.

And let's keep things marginally professional. I'll call out a broken software suite on its' failings all day but I won't attack you personally or imply you're lacking in some way. Let's not let this devolve into reddit.

Your response comes off as TLDR: "It's not a bug, learn to work around it, stop complaining." @Andy Heinzer at least attempts to have a productive discussion, though he does highlight a seemingly inbuilt issue with Atlassians' attitude towards development. Your last response does nothing to address my point that Atlassian is a multinational powerhouse with the resources to fix these types of issues with a KPI that isn't fifteen years.

[Nic Brough -Adaptavist-]

<sigh>  Adaptavist and Atlassian are separate organisations.  I've never represented Atlassian for anything.  Worked and appeared alongside them, yes, but not represented.

If you want to keep things professional, then don't accuse me of doing things I was not just because you don't like what was said.

If you'd read what I've said properly, you'd see that

I'm not saying "it's not a bug" - it is (developers might argue semantics over flaw/bug/problem, but I'm happy with bug, as it's something that's broken).

I do say "learn to work around it", but that's pragmatic - until Atlassian fixes it, you have to. 

I am not saying "stop complaining", I'm asking people to understand before they repeat a whinge that's already been discussed and explained in full.

And finally, the 15 years point still stands - it's not the length of time, but it is about the resources.  Download Jira's source code for yourself and take a look at the size of it.  Consider the number of developers Atlassian has.  Then take a look at https://jira.atlassian.com/secure/Dashboard.jspa for the public list of things they have outstanding.  Today, for Jira Server alone, there's 9300ish.  This, of course, ignores Cloud, Data Centre, and platform issues.  It doesn't show you internal issues, development plans, upgrade plans, restructuring plans, issues related to interfaces with other systems that are running ahead.  So, this bug, while annoying simply isn't a priority - it affects a tiny handful of us, it doesn't break anything significantly and there's a proven workaround which is not that hard to use.  Plus as Andrew assures us, it's hard to fix.  It would be like deciding to paint the outside of your house because it needs doing in the next 2-3 years while ignoring the hole in the roof and the subsidence.

[jbburf]

This is incredibly non-intuitive. I just went through the process of making a new workflow and then moving all of the items over to it. I just copied my original bug workflow and named the new one Original Name (v2).

This really should be much simplier, once a draft is published it should push you through the reassignment process (if needed). I don't know why Jira has to overcomplicate everything so much.

[David Holman]

 It reeks of a process dictated by engineering limitations. It certainly has nothing to do with how users work. #UXFail

[Deleted user]

Symptoms

When editing a draft worflow, some statuses/steps cannot be deleted and outgoing transitions cannot be added. This makes these steps and statuses useless.

Cause

JIRA contains specific code that removes the ability to perform these edits to occur on draft workflows.

A snippet from the workflow documentation:

Limitations when editing an active workflow

Please note that the following limitations apply when editing an active workflow (i.e. a draft workflow):

It is not possible to edit the workflow name (only the description) if a workflow is active.
Workflow steps cannot be deleted.
A step's associated Status cannot be edited.
If a step has no outgoing transitions (Global transitions are not considered), it cannot have any new outgoing transitions added.
A step's Step ID cannot be changed.

Resolution

There are two different options:

1. Publish the workflow after all steps are populated with transitions.
   OR
2. Edit the workflow in a disabled state (either copy it or disable the workflow scheme).

Source: https://confluence.atlassian.com/jirakb/cannot-add-transitions-or-delete-steps-in-draft-workflows-203392961.html

[Vinny Kawano]

I just ran into the same issue. I was able to create a new status and transition just fine at first. Then I published the draft and decided to go back and edit the workflow again. Now it's telling me I can't add a transition, which is strange since I was able to do it a few minutes earlier. There's got to be an explaination for this.

[Jared Lindquist]

ugh

1. Set custom workflow up for the service desk

2. service desk has been operating for a while 200+ resolved tickets

3. go to add a report about resolutions

4. can't because the status may be resolved but the "resolution" isn't set to resolved

5. rolls eyes 

6. create a post function to set the resolution on all my transitions

7. realize this isn't a retroactive update 

8. find how to bulk update here: 

https://confluence.atlassian.com/jirakb/howto-bulk-edit-resolution-321857142.html

9. oh wait, can't do that because can't edit draft workflow, even though that's what it says to do.

• Start by Editing your existing Workflow.

10. ಠ_ಠ

[Brendon Miszka]

This is terrible, please fix it.

[Pankaj Verma]

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.

[Bennie L_ Callies_ Jr_]

This still exists as of August 9, 2018.

The fact that I could create a new step and direct issues to it but be unable to direct issues out of it, is just... broken.

Unless a logical failure is detected, there should be absolutely no reason you can't add a new path for an issue to travel. The details and arguments have been fantastically stated by others during the month prior to my post. Thank you @Matthew Thurmaier and @James Ryan for saving me lot of typing.

## insert sharp, witty comment here, that I'm too tired to come up with right now.

[Matt Nelson]

Agreed, I added a step Not a Bug, put a transition to it, but forgot to transition out of it.  Now I face the pain of fixing it by copying my workflow and editing the copy and reallocating the projects to the new copy, just to add a transition.

[Andy Heinzer]

Hi everyone,
If you have found this thread, then you are among a number of growing users that have hit their head on this limitation of editing active workflows.  By now, it must be clear to you all that editing active workflows have a number of restrictions that are not obvious to new Jira administrators nor are they clearly laid out/easy to find in the official Atlassian Documentation space.  For that, allow me to apologize on behalf of Atlassian.  Sorry about that.  We are working to improve this.

To help correct this, I actually believe that @Brian Pohuski's post is the best explanation of the problem that most users see when they encounter this error.   I found that Brian in turn then created a documentation update request over on JAC, please see https://jira.atlassian.com/browse/JRACLOUD-68734
I believe that this request is actually the best place right now to vote for this issue.  Thanks @Brian Pohuski, appreciate your efforts here!  

Ultimately, I don't see a clear way to change the root behavior of making these specific types of changes to an active workflow.   There is actually a really high likelihood of data corruption/inconsistencies to allow users to edit an active workflow in the specific ways that trigger this error.   So I understand that many users that see this error believe it's a bug.  However I would ask that users that believe this is a bug take another look at this and try to see the potential problems this could cause from a data integrity aspect.   Suppose you already had a number of issues in a final state of Done, and then you changed the active workflow to have a new final state.  Suddenly your previous issues that were complete, have a resolution and are complete, but may never reach the newly created final stage in the updated workflow anymore.  To use the cliche, "It's not a bug, it's a feature" actually seems appropriate on some level here.  The fact that you see this error here, Jira has actually prevented you from doing something potentially unwanted to your own Jira data.  

In the mean time, the workaround of copying the existing active workflow, making the changes to that inactive copy workflow, and then associating that copied workflow with your project/issuetypes is really the best way to work past this limitation.   The process of applying a new workflow invokes a wizard that will help to move your issues to conform with this new workflow in ways that just does not happen when editing an active workflow directly.

Instead I think the more helpful means to progress this issue and be productive here is to update our documentation and better instruct/educate Jira administrator that are editing workflows here about this limitation.   It's clear to me from reviewing this thread that we, as Atlassians, have not done a good enough job on that front to date.  But I hope that this post helps to start to bridge that gap.

TLDR:

• Please follow the steps in the KB https://confluence.atlassian.com/jirakb/cannot-add-transitions-or-delete-steps-in-draft-workflows-203392961.html
• It's not a bug, it's a feature
• Please vote/watch JRACLOUD-68734 to help us improve/update our documentation.

Cheers,

Andy

[Bill H]

Hi Andy, 

I can't speak for everyone on this issue, but my concern is not editing a truly active workflow on an existing project, I understand the problems that could occur with that.

Rather, the problem for me is that you can't easily modify the workflow on NEW projects. I would think a very common process for people would be to create a new project and then tweak the workflow as needed. This would be before any issues are created. See Brian's post above.

[Andy Heinzer]

Yeah, I understand that.  But from the moment a project is created in Jira, it has at least one active workflow in place.   Even if you haven't created issues yet in that project, it doesn't change the limitation in regards to what you can and cannot change in an active workflow.

[James Ryan]

@Andy Heinzer

Thanks for taking time to answer, but your reply to Bill H above shows that you don't really grasp the true issue or the frustration we are experiencing. You mention one specific kind of change that could cause cards to be "orphaned", but that's a very specific case. This bug prevents a huge number of very simple, benign changes, even for projects that have no issues at all yet. How could there be a risk of "data corruption" in a project that has no issues? There are lots of other simple changes I'm prevented from making (adding new transitions, adding additional "Done" states, etc.) that carry zero risk of "data corruption".

Please don't sweep this under the rug as "working as designed, needs better documentation". Please listen to your users. Isn't that why you have this "Community" in the first place?

[David Holman]

> Suppose you already had a number of issues in a final state of Done, and then you changed the active workflow to have a new final state.

Alright, let's think that through like a product development team ...

Can the system query all Projects using that Workflow for statuses that don't exist in the new edit? Yes.

Can the system present these statuses (and an issue count for each) for the user's review? Yes.

Can the system enable the user to change each missing status to something in the new Workflow? Yes.

It's much like moving an issue. Not elegant, perhaps, but better than the existing solution.

IOW, don't use "it's a feature" as an excuse for poor or incomplete design.

[Andy Heinzer]

Hi @James Ryan,

Let me try to explain some more of the technical details behind this and I hope it might help explain my viewpoint better.   Workflows in Jira are stored in a SQL database.   Each status, and transition exist in specific entries of these SQL tables, and these elements in a workflow have unique identifiers and relations to each other.   There are elements here you can change in an active workflow that don't undermine these SQL relations.   But there are also elements here that if changed in an active workflow, would not then in turn update the specific jira issues that could be assigned to that workflow.  

I get it, "in a new project, what does it matter because I don't have issues yet?" 

Great question, and a good point.  But the checks that exist for active workflows are in place to prevent bigger potential problems, not just my one scenario.  Jira is not yet intelligent enough to make the check against an active workflow for issues assigned to that workflow to see if they are empty or not before letting you make these kinds of changes.   Instead workflows are all either active or inactive. Active = in use somewhere in Jira, inactive = not in use by any project/issuetype.

Since workflows can be shared across projects, checking one project would not be enough anyways.  Imagine having a Jira instance with 50 projects, each with 200,000 issues.   They could all be using the same workflow.  The check here would take a significant processing hit to complete against each project/issuetype in question.   Instead Jira is setup to check only if the workflow is active or inactive.  The number of issues potentially involved becomes irrelevant in this case.   I imagine it was designed this way for the sake of performance, but that's mostly a hunch.

But the process of associating a new workflow is at least able to check against existing issues and if their current states don't match the new transitions available.  If that happens, then Jira prompts the admin to assign these existing issues to new status instead.    This commonly has to happen when importing data from another system into Jira.

Please believe me; I do feel your frustrations over this problem.  It would be a better user experience if you could just make those changes directly.   But in my view the work-around of making these changes to an inactive workflow first and then assigning that to the issuetype are not that difficult to do, and in turn provide you these other protections of your Jira data.  

Forgive me if I am oversimplifying your argument here, but the trade off is avoid data loss for x number of Jira issues VERSUS save an admin 4-5 extra steps editing a workflow.  I believe the avoid data loss mantra reigns supreme.  I understand that you don't want to have to perform these extra steps to do. That's fair.  It is tedious.  It can be frustrating.   I too can feel the frustration around this.  

My intention is not to sweep your concerns under a rug as you put it, far from it.  But rather to help users that find this problem get past it one way or another.  If you feel a change to the code in Jira is the better long-term solution than simply making changes to inactive workflows first, then of course I invite you to create a suggestion on https://jira.atlassian.com/projects/JRASERVER/issues/

Maybe I am in the wrong in my approach here.  I accept that I'm not perfect. I can't guarantee Atlassian would implement the changes suggested there, but I am open to listen.

[Matthew Thurmaier]

Andrew, 

First: I really appreciate the time you are taking to discuss that with us, going into details, and taking some heat for Atlassian (the heat is well deserved for Atlassian, and ultimately has to go to _someone_, thanks for stepping forward and taking it).

Second: With respect to: Jira is not yet intelligent enough to make the check against an active workflow for issues assigned to that workflow I say this is really just an SELECT with an SUM aggregate. It should take between a person-day and a person-week of engineering and QA time, depending on how knarly the SELECT is.

You mention the performance hit. The performance hit is NOTHING compared to the time it takes to have a JIRA admin take the steps they must take now to implement the work-around, IF you want to do it the way you specify. HUMANS are expensive. Machines are cheap.

Third: If a process can be implemented in a work-around as described, with: A) copy the workflow; B) make the change; C) apply the copied workflow to the project ... THEN it can be coded. That it isn't coded is a matter of priority by the Product Owner(s) at Atlassian. We get that. But, these other discussions about performance, etc. are distractions. Just implement the workaround in code. Oy. Take the work off the humans and put it on the machines. That is what the machines are FOR. It's why we pay for _software_. 

Finally: To "get past it" Atlassian needs to step up and provide a SOFTWARE solution, not a HUMAN solution. We pay $ for the software. Or we go find OTHER software that DOES solve our problem. Market forces at work.

Thanks

[James Ryan]

I agree completely with @Matthew Thurmaier and was about to post something very similar. If the process of reactivating the workflow "provide you these other protections of your Jira data" (in the words of @Andy Heinzer), then it sounds to me like you already have a solution that works in code. Just reuse that code as a verification step when editing active workflows, and eliminate the extra steps of having to deactivate and re-activate.

Also, @Andy Heinzer, I think you need to remember your audience. JIRA users, by definition, know software development. It's what we do. You should use this forum as a resource. With respect, it sounds more like JIRA is just trying to placate us with excuses.

And if JIRA's position is "we have higher priorities" then just tell us that! This audience understands that better than any other.

[Victor Vucicevich]

Honestly at the end of the day I think we just need something better than a "You cannot do this" message, but instead a "You cannot do this, this is why, and here are the steps you should be taking to do this" message.

Would dissuade a lot of the frustrations we have, despite it still being silly overall. 

[Lindsay Brock]

+1 to what Vic said, at the very least a better error message would be an improvement.

It took a lot of googling before I found this post and finally figured out what the problem was. It was a massive waste of time that could have been prevented by a better error message and link to documentation. 

[Toby O’Sullivan]

I am here because I was trying to implement another of your workarounds because you can't bulk edit issues to add in a resolution:

https://confluence.atlassian.com/jirakb/howto-bulk-edit-resolution-321857142.html

However I was unable to add in a transition FROM a final state to itself. 
This would seem to be a different category of transition than the one that @Andy Heinzer mentions above that might incur data loss.

In the end I just went ahead and manually edited a hundred or so issues in their final state to add in a resolution.

[Brian Pohuski]

@Victor Vucicevich @Lindsay Brock

Agreed. I created a suggestion for that here: https://jira.atlassian.com/browse/JRACLOUD-68734 which is what @Andy Heinzer was mentioning. If nothing else, at least it will help reduce some confusion.

Definitely could use some votes or more user input directly on that issue if you feel up to it!

[Ethan Schwartz]

Adding my 2 cents to this --

The biggest pain point for me with this is the lack of clarity in the error message.

I'm doing something that ought to be dead simple which is adding a state and then creating a transition -- when I try to add the transition I get this error... but the linked page explaining the situation is not very helpful when it comes to understanding what you need to do to work around it. 

I would love to see some improvement in the documentation / help, and realistically it can't be walls of text (like this thread), it ought to be straightforward and easy to pick up quickly: "You can't add transitions to an active workflow.  Disable this workflow before editing it, or create a new workflow"

Thanks

[Nic Brough -Adaptavist-]

I'd agree the error message should be better.  It does say it in the documentation for creating workflows already.

Also, the error message should be more accurate: "You can not add transitions out of a status that does not already have an outgoing transition, when in draft mode.  Disable this workflow before editing it, or create a new workflow"

[Christopher Watson]

We actually have this issue. We have a custom 'Done' status in our workflow that we had to use in order to get our Kanban board and reports working. Problem is we have about 3,000 tickets in the system marked as 'Done' that Jira is not acknowledging as resolved and so all our KPIs are hundreds of hours out of whack per ticket.

From my point of view, talking about a 'new' system with no tickets is an edge case scenario. I was trying to edit the workflow of our subtasks to follow the same workflow as our primary tickets, when Jira hit me with this error. I couldn't get the tickets to transition from one status to another. I eventually found a workaround which I posted at the bottom of this post explaining how I had to set ever status to allow to be transitioned to from any status. So now all of our subtasks are manually set which looses any sort of automation functionality.

I also had to write up an entire guide on another thread on how to get jira to send an alert every time we have a new ticket come in. It's not just a single issue with Jira, the program as a whole is a cobbled together mess and while I respect @Andy Heinzer for actually coming on here, it still doesn't really help to explain 'It's a feature not a bug' because your worried about small edge cases and ignoring propper use cases.

[Alan Martinez]

I have the same problem. I'm not able to add a direct transition from a closed status to a to-do status. The solution on my case was to add a global transition to the to-do status by selecting the checkbox in the right "Allow all statuses to transition to this one" and then modify the post functions of the transition to clear the resolution field and this reopened my tickets without any problem.

I know that this shouldn't be the final solution but is a quick fix if you need to reopen some tickets, you can delete the transition after moving the tickets to the to-do column.

[Kasia Bobinski]

Trying to use the workaround for this problem suggested by users in this community but can't make it work. 

Can someone help please? Steps to recreate where I get stuck:

Create a brand-new project. 

Go to workflows tab. 

Add a status.

Click on status and Add a transition. 

Click 'Add'

Receive an error message 'You cannot perform this operation on a draft workflow. More Information' 

Whenever I try and create a copy in order to make any changes I need to edit it. Therefore creating a draft. Going round in circles. 

[Nic Brough -Adaptavist-]

I can see why the conversations above get complicated and unhelpful.

I think you are very very close to fixing it, but missing how to extract the fix from our conversations (because we barely mention it, mostly we're talking about how stupid a design flaw it is and why it's hard for Atlassian to fix it and actually how few people it affects!)

There is something missing from your description though.  You say "create project" then "go to workflows tab", but you do not say what you selected for a workflow or how.

I could wait for answer to that, but I would prefer to get you past the problem.

Let's say we stick with the new project you just created.  Go to the workflows tab and take note of the name of the workflow you have.  Now go to Admin -> workflows and find that workflow.  Copy it, and edit the copy, adding the transitions you need.

Then, go back to the workflow scheme and replace the old workflow with the edited one.  You might be asked to migrate if there are things Jira can't handle, but it will ask the right questions and give you the option to cancel changes.

[Pankaj Verma]

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)

But, 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.

[Kasia Bobinski]

Thanks Pankaj. 

The step I was missing is going to the Inactive section and editing from there.  

I found my copy of workflow in the inactive workflows section and was able to edit that. I was finally able to add a transition for the first time ever. YEY! 

A bit annoying though how you need to apply the workflow each time before you can test it out on your columns and see if it works how you imagined it to work. Ideally you could see the columns in situ and be able to play around with the Jira tickets, adjust that workflow and add/remove transitions to make sure it works.

Anyhow, using this approach every time you want to make a change to the workflow you need to create a copy. I am ending up with lots of copies. Is there any way to delete them? I did go to Active workflows and edit and delete draft. But the workflow stays displayed on the workflows page. It is not an active workflow as I did overridden it. 

Thank you so much for your help. 

[Pankaj Verma]

Good to hear Kasia that it helped you.

To delete all those Inactive workflows - 
Go to: JIRA Settings >> Issues >> Workflows -> Go to Inactive workflow section
There you can find "Delete" option against the Inactive workflows.

Hope this will help.

[Christopher Watson]

On a more helpful note, for anyone else' reference, I discovered a possible workaround where you can at least add a status (if that's what you were after) and set it to 'Allow all statuses to transition to this one'. This will allow you to manually set it to this new status and publish.

Not ideal, but hope that helps someone out.

[Ishita Datta]

The issue wasnt really sorted with any of the solutions on this thread. Any one tried anything else?

If some one from JIRA is here, guys please please dont torture users like this. JIRA is a very very complicated product already, which needs people to go through trainings and videos and the whole learning curve. To top that u guys are making this product like a never ending maze of confusing features. 

Sincere request, please see if going back to drawing board is an option.

[Nic Brough -Adaptavist-]

Please see Christian's answer from Jul 09, 2015

See also Andrew Heinzer's answer on why it's not an easy fix, and understand the point that although it would be nice to have it fixed, this is a low priority because it only affects admins, and only causes a few extra steps in a process for us.

[Brian Pohuski]

Hey Nic,

Just thinking outside the box here... is there a way the workaround could be accomplished via 2 scripts?

I'm just thinking script 1 would be pre-changes (to automate duplicating & renaming the workflow), and script 2 would be post-workflow edits (to save, activate in the scheme, and delete the old workflow).

Obviously a core change would be best, but, I empathize on the prioritization. A duct tape solution is better than nothing in the meantime! I am just not knowledgable enough on traversing workflows with scripting. I guess we would have to fit the multi-step process of converting any statuses as well. Anyone here know?

[Nic Brough -Adaptavist-]

Very good idea.  I especially like the split into pre/post, so that you would have a script that an admin runs to put themselves in a place where they can edit, then a second to do all the work of applying it.  There is a difficulty in the second script, in that Jira does loads of checks on "activate" and may start asking questions if the admin has done something to status on top of adding transitions.  But scripts would help simplify this a bit.

[Brendon Miszka]

1. I agree with @Matthew Thurmaier
2. I've upvoted JRACLOUD-17782 - Allow to delete a step from an active workflow if there are no issues in that step. I'm not sure it's the whole solution though. For new projects without any issues, any changes should be OK.

[Brian Pohuski]

Ethan, any chance you could add those suggestions within the comments on issue JRACLOUD-68734 and upvote? Clarity on the error message was the original intention of that issue. Constructive dialog is important.

[Brendon Miszka]

@Brian Pohuski I've up-voted your error message suggestion now as well.

[Deleted user]

Still has the bug?

[Nic Brough -Adaptavist-]

Wow, that's impressive.  You want to swap to an alternative system because of a trivial bug that only affects admins and is easy to work around? 

Don't get me wrong, it is silly, and I want it fixed, as I spend a lot of time fixing workflows.  But switching to a vastly inferior system because of it is a lot more silly.

[Stacy Story]

with our recent run in with the changes and inconsistencies to the renderers, added to this type of situation where a change that breaks expected behavior and creates more work to in turn be ignored for years. If there was a viable alternative, we would also switch.

I can honestly say atlassian is creating jobs, in that we have an intern that usually deals with this because we were spending 3 to 5 times as much as our subscription costs in skilled labor performing these types of workarounds.

Our admins/devops dislike the product, our devs try their best to avoid using it, the analysts complain weekly about it, customer service use it long enough to copy paste to a second system. Our jira intern hates using it but loves that he has a job. The only people that like it are the project managers because it has nice reports.

If atlassian isn't careful, someone is going to create an alternative and they will either have to acquire or watch subscribers jump ship, it is not a happy ecosystem they have going.

[Nic Brough -Adaptavist-]

>Our admins/devops dislike the product, our devs try their best to avoid using it, the analysts complain weekly about it, customer service use it long enough to copy paste to a second system. Our jira intern hates using it but loves that he has a job.

That paragraph smacks of a Jira admin person or team that have not engaged with the users.  It's probably been "designed" by people who don't have to use it, and/or higher level people who thing they should enforce what they think is the right process by inflicting poor choices on the users.

Rather than trudge along hating it and wasting time on something that sounds broken, take a step back and re-evaluate.  Is it really the software?  Is it actually your processes?  Or the setup of the software?

Could you be objective about it?  Might it be better to get an Atlassian partner in to have a look at what is broken?  Or evaluate other products, bearing in mind the cost of massive change and having to re-integrate everything?