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

How to force user to select a resolution

Valentijn Scholten

Hi,

On the 'Close' issue transition we have a 'close issue' screen which, among other fields, asks the user the specify the resolution for the issue.

We used to have the default for resolution set to 'Fixed'.

However, lots of users just leave this default and close the issue with resolution is 'Fixed', while in reality the resolution should be 'Duplicate', 'Canceled', 'Functions as designed', or something else.

I decided to remove the default of Fixed, hoping this would force the user to choose a/the correct resolution value from the dropdown.

What happens instead however, is that the first resolution in the list becomes the default (Incomplete).

Which is not the expected/desired behaviour.

Is there a way to have JIRA render an extra option on the top of the list saying "Select a resolution...." or something like that?

Valentijn

Accepted answers

All comments

John Bayne

Add a validator to the workflow transition to make the field mandatory.

Valentijn Scholten

The field is already mandatory. The issue is that JIRA selects the first value in the list as default when rendering the screen.

Nic Brough -Adaptavist-

Technically, it's not "mandatory" in Jira speak. The field is optional, otherwise you'd have to have it on the create screen, which would be pretty useless. Your problem is that when you do place the field on a screen, it does not have an "empty" option, and defaults to the first value in the list, so you always end up setting it to something.

To "fix" this, you need to do two things:

Hack the field template to provide a "null" type empty option at the top of the list
Now you've added the empty option, you will now find that the resolution is optional and the users can use the null option to leave it blank. So you need to add a validator to make it mandatory for them to fill it in.

Note also that point 1 will let people mess up your resolutions in quick-edit if you place the field on the "edit" screens, so the standard advice to "never put resolution on an edit screen" still stands.

Valentijn Scholten

I was afraid this would be the only option, thanks Nic.

(How on earth can Atlassian accept this is acceptable software?)

Nic Brough -Adaptavist-

The resolution field handling is a legacy kludge in my opinion. I'd have redesigned it in Jira 2 if I'd been the product owner.

Valentijn Scholten

Just found out that if you set a default, which is *not* the first in the list, it won't work. JIRA will keep selecting the first in the list as default....

Paul Alexander

I'm unsure why the easier method isn't provided here. OP didn't say if they are server or cloud user. I'm cloud and you simply to go the Administration/Resolutions screen, and click the "Clear" defaults button at the top. The user is then asked to pick one. Validation in the workflow can enforce a value as needed.

Nic Brough -Adaptavist-

Because you couldn't do that at the time the question was asked.

Valentijn Scholten_ooatqz

I can do that in my JIRA 6.3.4, but it doesn't work.

Nic Brough -Adaptavist-

Paul is on Cloud at 6.4, so I assume it's a new function in there, but I don't have one to hand where I can check. Like you, the 6.3 I'm using at the moment still behaves the way I described in my original answer.

Tim Ryan

Anyway you can elaborate on "hack"?

Nic Brough -Adaptavist-

Open up the application server installation in a file manager, find the template files that render resolution, and change them to forcibly add the "none" to the list. Do this while JIRA is offline of course, and keep a backup (i.e. do it in test first and check it works). The file used to be called resolution-edit.vm, but it may have moved or been renamed

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration