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; } } }

Transitions should not require a resolution

Damian Romard

This is a recent change that I cannot find a cause for. When developers are transitioning through the workflow, especially to QA Validation, JIRA is requiring them to set a resolution.

Previously, Resolution was only required when closing an issue. There are no intended resolutions for JIRA items that are "in progress." All items are intended to be resolved (closed) or unresolved (open).

I've had to create a (fake) resolution of "continue" to allow these transitions to be satisfied.

Looking at the transition to QA Validation, there are no resolution conditions, validators or post functions.

Looking at the Workflow, there doesn't appear to be anything requiring this behavior. All states can move to all states without restriction.

Can anyone offer a suggestion of additional Settings that may point to this need for a "resolution" when it is not expected to be needed?

Accepted answers

All comments

Alexey Matveev

Hello,

Have a look at the field configuration scheme for the project. Maybe the resolution field is set as required there (project settings -> fields).

Nic Brough -Adaptavist-

>I've had to create a (fake) resolution of "continue" to allow these transitions to be satisfied.

ARGH, no, get rid of that NOW. You are resolving open issues when you do that. Jira sees them as resolved, so all your reports are going to break.

Go to the transition screen on this transition and remove the resolution from it. Then remove the admin rights from the admin who added it, and get them some admin training.

Damian Romard

@Nic Brough -Adaptavist-I understand your outrage but we could not transition items into QA. We looked for the root cause and other workarounds and ended up settling this while waiting for helpful feedback from the community.

I agree that this is not a solution and should not be considered resolved. Hopefully @Alexey Matveevidea leads me to a proper fix.

Nic Brough -Adaptavist-

It doesn't matter about "could not transition" - having a stack of issues that appear blocked (but report accurately) is a LOT better than having the same stack of issues report complete nonsense, and when you've fixed the root-cause, go on to need some quite complex fixing.

Given your screenshots (which are great because they tell us a LOT), there are three possible things wrong left to look at.

The field configuration has a mandatory resolution. Remove that (and the admin who added it, until they've had proper training)
The transition screen has the resolution on it. Remove that (and the admin who added it, until they've had proper training)
Some App making things really broken. Harder to say how you got there.

Damian Romard

@Alexey MatveevI checked the projects being affected and the general settings for fields and field configurations. I did not see any instances of "resolution" being required.

Alexey Matveev

Ok. Then check the workflow for this issue type. There must be the Field Required validator for the create issue transition.

Nic Brough -Adaptavist-

Resolution is not really "mandatory" like other fields. You can set it as such in the field configurations like other fields, but then you have to set a resolution when creating an issue!

Generally, resolution is technically optional in Jira terms. You don't have to set one when editing or transitioning.

But, there are two things that could be making it appear mandatory

There is a validator on a transition that requires it. Users will be thrown back to the previous screen if they try to commit a change with an empty resolution.
The code for resolution does not offer the user "none" (representing "empty"). If you put the resolution on a screen which allows data entry (create, edit or transition), then a value will always be selected for it and a resolution set!

So, my guess was that an admin added it to a transition screen, and it needs to be removed!