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.
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.
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.
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.
Thanks for the full context. I'll need to chew on the bigger problem for a bit, but short answer: it shouldn't affect performance much at all. But yeah, maintenance would suck.
This is where it would be useful to have on the Premium tier which allows for many more multi-project rules, in which case you'd only need to setup the 40 rules *once* and they'd apply across all of your projects.
But like I said, I'm trying to think if there's another way to approach the problem. I have to imagine others might have some ideas, now that you've fully fleshed out the scenario.
Thanks - I appreciate the help. For my 2 cents, the real long term solution needs to involve showing ALL transitions again, because this behavior breaks SO MANY workflows. Transition names were more than just a label for the destination - they were about the journey. They provided a path of action, and allowed people to make minimal, elegant workflows.
Consider this scenario: I have 3 buttons from Open to closed:
Each one transitions to Closed but automatically sets the resolution value and performs their own separate post functions.
NO LONGER POSSIBLE.
(EDIT: after testing the workaround in the subsequent response, this assertion appears untrue)
Imagine you have a Sync button that you use, which triggers a series of post functions for data retreival, syncing a series of external data (like nFeed) custom fields.
NO LONGER POSSIBLE
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!)
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.
I hate to sound like an old man (but wait, I AM!), but "In my day, we didn't even have the option of editing active workflows! We *always* had to make a copy of the workflow and switch it in."
Anyways, it is documented, but kind of buried:
The following limitations apply when editing the draft for an active workflow:
It's not possible to edit the workflow name (only the description) if a workflow is active.
- You can't delete statuses in active workflows. see Cannot Add Transitions or Delete Steps in Draft Workflows.
- If a status has no outgoing transitions (Global transitions are not considered), it can't have any new outgoing transitions added (regular or global).
- You can't change the step ID. See Cannot Add Transitions or Delete Steps in Draft Workflows.
To make any of the modifications listed above, you need to copy the workflow, modify the copy, and then activate it.
Weirdly, the most recent release notes suggest the fix or something similar is being rolled out, but I can’t be sure. See https://confluence.atlassian.com/cloud/blog/2021/01/atlassian-cloud-changes-jan-18-to-jan-25-2021#AtlassianCloudchangesJan18toJan25,2021-jira.platform under the section “Looping transitions get their own Actions button in the issue view”
My guess is that this covers the looping transitions I’ve described above and NOT the ‘all status’ to ‘itself’ global transition you need, but it would suggest this might follow on soon
Hey there Cloud Community members! We’re excited to give you the first glimpse of the new home for business teams on Jira — Jira Work Management. Jira Work Management is the next generation of J...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events