nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is it possible to have the selected Transition display in the issue's details tab under the current Status?

jukrzy

What I would like to have happen is to have the transition that was selected to display right under the Status in the details section of the issue.

Example:

Status: In Progress

Transitions: Gather Info, Analyze Info, Prepare Info

Let's say all three transitions are linked back to In Progress. Depending on which transition was selected, I would like to have it displayed with the current Status it is in. So if I chose Gather Info. I would be under "In Progress" with "Gather Info" underneath in it's own field in details. I'm trying to limit the amount of statuses and custom statuses used by creating transitions to replace those statuses.

I've searched but I believe my question is too specific to find any results. Thank you in advance.

Accepted answers

Nic Brough -Adaptavist-

That sounds very confusing and counter-intuitive to me. If I go through a transition, either it needs to be clear that it is an edit thing, or that it changes the status.

Without a change of status, how is the user going to know that things are progressing? If I look at an issue that says "in progress" in the status, then it's in progress. Your three arbitray transitions are meaningless. They clearly need to be done in a certain order, and that is exactly what you should use the workflow status to do. (If they were not dependent on each other, I'd be reaching for subtasks)

If you insist on this horrendous bodge, then I would create three tabs, one for each of the three non-status. Your users still won't have a clue what the actual status is, your reporting will be shot to hell, but at least the fields would be logically grouped. And it's not going to stop people doing things in the wrong order either.

If you want to go further than grouping the fields up, then you'll need to start hacking the core code to rearrange the screens.

All comments

Nic Brough -Adaptavist-

That sounds very confusing and counter-intuitive to me. If I go through a transition, either it needs to be clear that it is an edit thing, or that it changes the status.

If you want to go further than grouping the fields up, then you'll need to start hacking the core code to rearrange the screens.

jukrzy

Thanks, my ultimate goal is to clean up the custom-made statuses and create a more standard approach to the workflows. That's the reason I asked if it was possible to have the transition display with the current status, to show where the status has come from and how it got there.

Nic Brough -Adaptavist-

I've inherited Jira systems with status all over the place too, so I do understand how you feel. But I think you might be overdoing the housekeeping here - your suggestion doesn't allow you to control the order in which things happen, and you lose standard intuitive reporting on what needs doing (your users will want to report on "stuff that needs analysis, as we've gathered the information". Which you can't do in your scheme because all they have is "in progress" covering three status). I'd do a lot to chop down the volume of extra status you've got, but reconsider *why* you have them - this one feels like a valid usage.