-
Bug
-
Resolution: Fixed
-
Low
-
9
-
Severity 3 - Minor
-
Summary
Two transitions to the same status with different conditions. Only one should display in the sprint board, according to the condition, but both are showing up.
Steps to Reproduce
- Create a workflow with two statuses, e.g. To do and In Progress.
- Set two transitions to In Progress with conditions. (e.g. One with transition with the Original Estimate field =! NULL and the other one with the Original Estimate field = NULL)
Expected Results
When moving an issue from To do to In Progress in a Sprint, you should see only one transition, according to the condition which the issue matches.
Actual Results
When moving an issue from To do to In Progress in a Sprint, you can see both transitions and when you drag the issue to the transition which does not match the condition, an error occurs:
Can't move (issue ID). You might not have permission, or the issue is missing required information. If you keep having this problem, contact your JIRA Administrator.
Workaround
No workarounds.
- mentioned in
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page")
Page
Failed to load
[JSWCLOUD-15864] Transitions that do not meet their conditions or validators appear in column
Raluca Roncu
added a comment - I still have this issue when simply trying to move one subtask from one status to another (the workflow is well set)
Raluca Roncu
added a comment - I still have this issue when simply trying to move one subtask from one status to another (the workflow is well set) Hi Everyone,
A fix for this issue has now been released. If you are still being affected by this bug please raise a support ticket at https://support.atlassian.com and quote this issue.
Regards,
Luke Esther | Atlassian
David Swain
added a comment - I have just had to raise a support request to turn this off on our instances too.
In our workflow there are some transitions which are restricted based on user. These are offered but will always fail for other users. How is it a good thing to offer transitions which will always fail? Surely this will only ever cause problems and make things look broken?
The explanation from lesther says that it's to remove loading times when picking up the ticket. If that is the only gain, I'd suggest it's not worth the problems that it causes in non-trivial workflows. Possibly the "which transitions are available" query could be started on mouseover rather than click-drag to reduce delay without messing up the available options... or offer all, while doing a check in the background which would then update the available options.
David Swain
added a comment - I have just had to raise a support request to turn this off on our instances too.
In our workflow there are some transitions which are restricted based on user. These are offered but will always fail for other users. How is it a good thing to offer transitions which will always fail? Surely this will only ever cause problems and make things look broken?
The explanation from lesther says that it's to remove loading times when picking up the ticket. If that is the only gain, I'd suggest it's not worth the problems that it causes in non-trivial workflows. Possibly the "which transitions are available" query could be started on mouseover rather than click-drag to reduce delay without messing up the available options... or offer all, while doing a check in the background which would then update the available options. I would need more explanation about this feature before deciding to exclude us from it. Is it possible to get a full explanation of the feature?
Hi trenchrats, this behaviour is a known change which comes from a newly released feature. The feature removes all loading times when picking up and moving issues on a board. If you would like this offending behaviour reversed (along with the feature), please raise a support ticket and a support engineer will be able to exclude your site from the feature.
We are seeing the exact behavior. It seems to have started sometime last week, perhaps Thurs.
I posted on Atlassian Answers with an example of the behavior we see. https://answers.atlassian.com/questions/61583356/workflow-conditions-ignored-on-active-sprint-board
I still see the issue. I'm trying to move a subtask from Active board. Transition - CLOSED from To Do.
I pretty much can't do anything after I close the issue.