This issue is still dumb

I'm in the SAME situation - cannot add transitions from "Done" to any other state.

Why is this issue closed?  This is a bug, not a feature.  How can this still be a problem after nearly a DECADE?!?

I just discovered that I screwed up by adding a workflow state with no outgoing transitions and now it's apparently going to cost me an hour or two to fix that.  Thanks, Atlassian.

This is not flippin "Closed" – This is still a Bug, from 2008?!!?!!!!!!!!!!!!!!!?!!1?!/1 FLIPS TABLE

I tried the workflow migration, it failed, still troubleshooting, but anyway I am now stuck with these JIRA that is unable to transition out.

This is a silly "feature", JIRA admins are responsible not to break workflow, not Atlassian... now look at how many complains we got

Greetings –

Here's a logic way of getting into this situation

• create project 'foo' with copy of 'simple workflow'
• edit final state of workflow to be 'done'
• assign workflow to project, etc
• realize that the created vs resolved widget doesn't play well with "Done" – only "Resolved"
• try changing "Done" to "Resolved" in custom workflow
• see no option to delete "Done" and force a bulk change
• try deleting all transitions to un-grey-out the "delete" button for "done"
• realize no bulk change options are available to state since there are now no "transitions" from "done"
• **UNABLE* to add new transitions to draft to be able to batch-transform issues from "Done" to anything else

Can you please watch & vote on JRA-19091? Many thanks, Rosie

Atlassian, you should really answer us why you need that closed state and why you consider this fixed. It's certainly not fixed! Please listen to your users andreask

Surely it should be technically possible to reassign the 'completed' status to a different/new step,
...and then allowing the user to add additional transistions to the desired step.

Dear JIRA guys, how on earth can you call this FIXED?
Or can you not REOPEN this ticket due to some silly osworkflow constraint?

Same problem as Richard..
I need to add addional steps to the last step in the workflows my predecessor created.
I also want to be able to REOPEN items but I can't add outgoing transitions.

We were able to do a workflow migration as suggested here. However I would definitely get rid of this catch 22 situation. In the standard workflow "closed" still allows "reopen", so precisely why does there need to be a "completed" state in any workflow? It's clearly not needed for normal processing. If that state is eliminated wouldn't the problem go away without anything getting broken? Not seeing the logic.

Hi, being relatively new to Jira workflows, I created a "hold" step with an incoming transition but no outgoing transition (figured I could do that later). I put several issues on hold. They have extensive work logs etc. Today I needed to reopen one of those issues and found that I couldn't, and couldn't create an outgoing transition due to this issue. These "hold" issues are not regarded as "resolved" by Jira, I can't "close" them. I can't "reopen" them. I can't delete them because we need the work log info to prove to our customers we were doing work.

Cloning doesn't preserve the work logs. What do we do? I really don't want to mess around in the database.

I'd very much recommend putting in something that prevents people from being accidentally trapped by this idiotic "feature"

I agree with @Danny.
I've just played around with Jira 4.4.4 and met this limitation today. To me this is annoying as I am building the workflow as I move along. All steps are not in place as the customer would like to tag along in the creation of the workflow. Now you are telling me that I have to create a new workflow, assign issue types, etc., in order to continue? This should be raised as a change request. "Fixed" is just a ridiculous resolution on this issue.

Hello,

With all due respect, this should be regarded as a Feature Request, and I should be able to vote on it. The reason why the feature doesn't exist is because it would be difficult to implement due to architectural limitations. However, a determined user can work around this limitation. If a user can work around the limitation by jumping through hoops, then a developer can work around the limitation by writing an feature to jump through hoops for us.

If the implementation of this feature is too "expensive" then either mark it "Wont Fix" or leave it unimplemented and open to voting.

Calling this a feature is a spit in the face to users running up against what to them is an arbitrary limitation.

Thanks,
-danny

Please see the explanation for this behaviour:
http://jira.atlassian.com/browse/JRA-15964?focusedCommentId=135618&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-135618

The limitation regarding transitions is documented here:
http://confluence.atlassian.com/display/JIRA/Configuring+Workflow#ConfiguringWorkflow-Limitations

Please let me know if I've misunderstood anything — many thanks.

Problem exists in 4.2.1 and 4.2.2, too! I had an Support Request for that: https://support.atlassian.com/browse/JSP-69581 . There you can find a small video to reproduce this in a fresh installation. Could this one be reopened?

Hi Markus,
I'm not sure that the problem you describe is related to JRA-15964. Could you please contact http://support.atlassian.com ?
Many thanks,
Rosie

Hello *,

I got the same situation that we needed to set the resolution field mit a specific value but adding a transistion is not possible.

As we don't dare to directly edit the database We changed the RESOLUTION field of relevant issues to the desired resolution id.

Problem ist now that all dashlets do not see these resoloved issues as resolved and e.g. the "Created vs- Resolved Chart" dashlets does not counts the updated issues in the green line.
=> Is there any additional database table holding some update information and which we nned to refresh to distribute the info about new resolved issues throughout the system?

Any feedback and help appreciated!

BR, Markus

Hi,

I added this information a couple of months ago (please see FishEye diffs).

However, to make the information easier to find, I have now added a sub-heading "Limitations":
http://confluence.atlassian.com/display/JIRA/Configuring+Workflow

NB. I have only made this change to the JIRA 4.0 docs (on CAC), not in the 3.x docs (which are still in Forrest, and will remain there).

Do you think this makes the limitations visible enough?

Many thanks,
Rosie

Without going around OSWorklfow and manipulating its database tables directly I believe it cannot be fixed.

We would prefer not to manipulate the database tables underneath OSWorkflow.

However, on purely technical level, it is possible to achieve.

So based on osworkflow feature set, are you saying this is a feature that cannot be fixed?

Yes, we should update the documentation.

Andrew, could you please have a look?

Hi Andreas,

Alright, thanks for the explanation. Maybe we could add this into the documentation also? These are the only limitations listed:

• Existing workflow steps cannot be deleted.
• Associated status for each existing step cannot be edited.
• Step IDs for existing steps cannot be changed.

Regards,
Timothy Chin
JIRA Support Engineer

This is not a bug but a feature .

You basically can't add a transition in a draft workflow to a step that doesn't have any outgoing transitions (or no transitions at all like in this case). See my comment about this.

The problem is basically that osworkflow (our workflow engine), will mark the workflow for an issue as 'completed' once you enter a step without any outgoing transitions. If we now would come along and all of a sudden add an outgoing transition to such a step, we'd break osworkflow's state for that issue, and we'd get errors thrown if you tried to transition the issue out of the 'completed' step. We therefore don't allow this for draft workflows, and you'll have to do a full workflow migration to add such a transition.