See https://jira.atlassian.com/browse/JRACLOUD-72667
Is there any way around this? Is there a way to transition to a new status and then automatically transition back to the previous status - WITHOUT the use of a plugin?
Use of automation rules is OK as that is a part of Jira Cloud BUT I cannot use anything requiring additional money.
An Automation rule will work for this, and if you scope it to just a single project, you are allowed unlimited executions.
I appreciate the response but am looking for an answer
I've looked into rules, and if that is an option it's far from obvious. Please elaborate.
Oh hi, sure, here's what I came up with off the top of my head:
The question is, what do you want to do with the ticket when it goes into the other Status? In my case, I just sent an email, but you could also Edit fields, etc.
But at any rate, hopefully this shows how you could have the ticket get transitioned back within an Automation rule. Note that the Scope is limited to a single HELP project. That's what keeps it "free".
Ah. Yeah, your solution kind of works for one status. Now.... assume you have 10-15 statuses.
At ANY point in the workflow, an issue might need to be flagged with one or both of two attributes. Lets say one flag is paused and the other is delayed. Those aren't the actual values, but it works for this discussion.
The workflow I designed involved 4 transitions, that could be initiated from any status, going back to itself:
The Pause and Delay transitions would use a screen with a single text field, telling the user to specify a reason why they were taking action. This is why a transition is necessary, as opposed to simply letting users edit the fields.
So why not just make these statuses? Well, for one thing, an issue might be paused, but not delayed, or vice versa, or both. But even that's not the main issue.
I need the ability to flag an issue ANYWHERE in the life cycle of the issue and remain in the current status. For reporting purposes I should be able to build a dashboard gadget like a pie chart showing all issues that are paused, with slices showing the various statuses.
The only way I can see to do this is by building each flag as a status, creating transitions to each flag from every status, and then building automation rules for every source status to return the issue back to the source status.
So - assuming there are 10 source statuses, with two flags, and two operations per flag (one to set and one to clear) we are talking about building - AND MAINTAINING - 40 automation rules, and also having to build to/from transitions to both flag statuses from each status - making the workflow diagram look like absolute, unreadable dogsh-t due to a mess of transition lines.
And that's just for one project, since the rules would need to be limited to a project basis. I'm creating two projects. I thought I was going to be able to do the work once and use the workflow in both projects. Now I need to create 80 rules. And another 40 per new project afterwards.
This isn't elegant. Its not simple to maintain. A change in one place will require so many ripple changes.
In reality none of this NEEDS automation rules. It could all have been done simply with 4 transitions and a few conditions.
This problem goes far beyond my implementation. This is going to break the workflows of existing customers as they are forced to transition from Server to Cloud.
The problem with any workaround is the it's not going to scale well beyond a certain number of statuses as you recognise yourself.
However, rather than an automation, I'd probably simply create self-referencing transitions for each status with each transition attached to your pause/delay screen. If your workflow has 10 statuses, you need 10 transitions (or probably fewer as the last status would be a done/closed status).
e.g. you have a transition from 'in progress' to 'in progress' called 'in progress pause/delay' and so on.
Yes, it's clunky, and an 'all statuses' to 'itself' is the real solution, but it only takes a minute to create - you use the same transition screen every time - and from the end user-view it's 'sort of' consistent (up to a point!)
Hi Rob - Since they are working on the issue right now, I suspect it will get solved prior to forcing everyone to the new view. In the meantime, why not just use the old view for these issues until the fix is there?
In the address for that issue, you can add this to the end of the URL to quickly switch to the old view without having to change back and forth in the Personal Settings/Jira Labs.
?oldIssueView=true
Interestingly enough, I was not able to do so with an active workflow
But I do seem to have been able to do this with a draft that I then replaced the active one with. Interesting. Thanks for the idea, this is at least a potential workaround.
Thanks - I cant divulge more but that's not an option.
Yeah, it sucks to have to wait, but they have added this note:
Hi everyone, thank you for your interest surrounding this ticket. Before we begin transitioning all users to the new issue view on 31 March, 2021, we’ll be solving this problem. Watch this ticket for updates as we progress and please add a comment for any questions you may have.
In this particular scenario waiting it out is not an option.
When the draft thing shows up, you just need to copy the workflow then edit the new inactive workflow.
After that just replace the active workflow with your new one.
Yeah that's how I was able to get it done. This is a workaround for what should be standard behavior. Aren't we able to edit active workflows? What's different here?
This is sub-ootimal, and opaque. Why is this a problem? I checked the docs, this scenario is undocumented, so I don't know what the problem is - only that I have to work around it - and that's the whole problem here. Finding workarounds for functionality that was flawless in server but not Cliud.
It looks like you're new here. Sign in or register to get started.
