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.
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:
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.
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.
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:
Another thing you can't do on active workflows (drafts) is to delete statuses
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...
When editing a draft worflow, some statuses/steps cannot be deleted and outgoing transitions cannot be added. This makes these steps and statuses useless.
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.
There are two different options:
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.
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.
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.
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.
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.
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.
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:
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.
There are requests and bugs in Atlassian software that are
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?
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.
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.
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.
>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?
Might it be better to get an Atlassian partner in to have a look at what is broken?
Create more jobs 🙌
If atlassian isn't careful, someone is going to create an alternative and they will either have to acquire or watch subscribers jump ship
Case in point: Trello.
There are alternatives, but they don't meet the unproductive demands of executives because the alts are focused on productivity. And so the cycle of Atlassian's growth continues.
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.
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.
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.
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?
> 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.
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.
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.
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 @Andrew 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, @Andrew 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.
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.
+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.
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:
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 @Andrew 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.
Agreed. I created a suggestion for that here: https://jira.atlassian.com/browse/JRACLOUD-68734 which is what @Andrew 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!
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.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG