Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

New Jira Issue View does not show transitions from a status to itself - how can we work around this?

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.

3 answers

2 votes
John Funk Community Leader Jan 30, 2021

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

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.

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:

Screen Shot 2021-01-29 at 6.18.16 PM.png

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:

  • Pause
  • Unpause
  • Delay
  • Resume

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. 

So, thinking about this a little more, I can allow all transitions to/from the flag statuses, but that still requires 40 rules per project.  How is that going to affect performance, on top of the maintenance issues?

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:

  • Not Bug
  • Duplicate
  • Will Not Fix

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!)

Interestingly enough, I was not able to do so with an active workflow

Capture 2021-01-30 at 12.16.51.png

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.

image (13).png

John Funk Community Leader Jan 30, 2021

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.

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.

https://support.atlassian.com/jira-cloud-administration/docs/work-with-issue-workflows/#Workingwithworkflows-editingActiveandinactiveworkflows

Like # people like this

Hahahahahaha, nice

Anyway, I'm right there with ya man, been an admin since Jira 3.  

I want to love Cloud, really :) And I'm sure we all will once these things are ironed out.  Thanks again!

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 

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira

Announcing the waitlist for Jira Work Management

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...

141 views 3 7
Read article

Community Events

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

Events near you