Resolution Field

[Corinna Führing]

which value can I add to Resolution field, if I w ant it to be empty by default ? (= unresolved) I think JIRA ships with value Fixed as default. But that s disturbing since a task i just created, c ant be already fixed ?

[Rahul Aich [Nagra] · Accepted solution]

If you want it to be empty, just remove it from the screens and it will stay as Unresolved.

Although it is not recommended because a lot of reports like created vs resolved and resolution time reports depend on the resolution field information.

Rahul

[Nic Brough -Adaptavist-]

You can't leave it "empty by default".  What Rahul is getting at is that if you put the field on a screen for create or edit, then it will take a value, and hence the issue will appear closed.  Remove it from your create/edit screen if you've added it there.

You should only put the resolution field on transition screens, and only on transitions that go from a status you want to think of as "open" to status that you see as "closed".

[Corinna Führing]

ok . i got it ..and this way the reports will also work perfectly since I have unresolved issue, if I do not have it on the screen (actively). There is no Reolution unresolved under Resolution names or ? Means in this case one of our emplyees must have added it...?!

[Nic Brough -Adaptavist-]

No, there should be NO "unresolved" type resolutions on the list of resolutions.  If there are any, then remove them, as they're wrong.

This is a case where the technical explanation is actually helpful...  JIRA regards the resolution field as a flag to see if an issue needs any attention. 

In the database, the field for any issue can either be empty (null), or it will be holding a value (From the list of resolutions). 

If the field is "null", JIRA treats the issue as "something needs doing", and it shows that by displaying "unresolved". 

If the field has anything in it, then the issue is "resolved", and it displays the value from the resolution field, and displays the strikeout on the id in some places, and ignores it in some reports etc.

Some inexperienced admins make the terrible mistake of adding words like "unresolved" or "none" or "open" to the list, thereby breaking it - there is something in field, so the issue is resolved.  Doesn't matter that it says "open", the field has a value, so the issue is resolved.

[Corinna Führing]

ok thanks....i understood before but now got somehow insecure,,,,,it s just really not any easy concept for somebody really new to Jira...the sceen stuff and so..but i am happy i am no more that new....

[Denison Wright]

It'd be great if JIRA's engineering team could look to improve that. That implementation led to a terrible user experience where one needs to RTFM to understand how to deal with Resolution = Unresolved properly.  One can imagine several other implementations that would have avoided the problems listed above and given the user a much more intuitive experience.

[Nic Brough -Adaptavist-]

It's a historical headache - made sense in JIRA 1, but should really have been quietly shot in 2+, and replaced with a proper meta-status system

[Laurie Rzepka]

I'm one of these:  Some inexperienced admins make the terrible mistake of adding words like "unresolved" or "none" or "open" to the list, thereby breaking it - there is something in field, so the issue is resolved.  Doesn't matter that it says "open", the field has a value, so the issue is resolved.

Where can i remove the resolution field that i've allowed them to edit?

[Nic Brough -Adaptavist-]

Ok, you'll need an admin account.

First, if you've got none/open/unresolved resolutions, rename them to something like "do not use me".   Nip into Admin -> Issues -> Resolutions and rename them. 

Now scan the volume of the problem.  You need to search for "resolution in (list of broken resolutions".  Save that filter and give it a sane name.  You'll probably want to use it in a couple of dashboard gadgets to help you identify issues that need updates.

The main thing to check is the status of each "resolved but broken" issue.  If they are all in status that means done/ended/closed/whatever, then you can skip the next step.

If you have issues with broken resolutions and they are "open" type status, then you need to get the resolution cleared out.  You can't edit it away, you have to push the issues through transitions with "clear resolution" on them - usually "reopen issue" transtions.  I usually end up editing workflows to add in "go back to same status, but clear resolution" transitions to do that, or using the script built into the Script Runner add-on.

Once you are in a state where you have no issues with bad resolutions that are in an open status, you can simply delete the bad resolution - JIRA will ask what you want to swap the resolution to.

[Laurie Rzepka]

Thank you I have the filter saved and there's plenty.  I can't seem to find where in the workflow status is a "clear resolution"

[Nic Brough -Adaptavist-]

It's a post-function that you need to find in the transition settings.

[Deleted user]

I am trying to find a "good case" for resolution.

My team has added "unresolved", "won't do" and "duplicate" to the resolution options. They are mostly used by testers and for managing bugs. Marking a "double bug" for example, or for when they have found a defect which is not breaking/important and thus we will not fix.

Okay. Anyways.

That is how it is NOT supposed to be working.

So, which fields should we be using in resolution? Only Null and "Resolved"?
Are there other "Resolved" cases in which you'd name it differently?

I will fix this issue in our backlog soon, but before that I'd like to know how we SHOULD use it. Including using multiple "resolved" options, or only that 1.

[Nic Brough -Adaptavist-]

Most of your resolution values are probably fine, and how you should use resolution is down to what you want to report on.

Resolution is "a brief phrase to give you a rough idea of why something was resolved".  It's for reporting mainly - "We resolved this because it's <a duplicate>, <fixed>, <cancelled>, <not a bug>, etc" - those may have different reasons per issue, which I'd hope to see in the comments if they matter, but it's the broad class of "why" that matters. 

For example, it can be useful to see "we closed 100 bugs, but 87 of them were duplicates" - it should lead you to examine why people are raising it so much and separately.  Metrics like "how many weren't actually bugs" and "we fixed X this week" can also be useful.

The words you use should be drawn from what you want to report on.  I tend to look at lists of resolutions with less than 4 as being pretty useless and over 20 confusing.

You can't have multiple resolutions, in the rare cases where an issue falls into more than one type of resolution, whomever resolving it should pick the main reason.

Now, on to the bad thing you have done.

Take out "unresolved" and burn it with fire.  NOW.  Any resolution phrase that says "not resolved" is immediately contradicting the fact that the issue is resolved.  The issue is resolved when it has a resolution, no matter what that resolution says.

Change your workflow so that when an issue is re-opened (unresolved), it clears the resolution field.  Then rename "unresolved" as "no no no no no" and work through the issues that have it, correcting their state and actual resolution.

[Rolf Lader]

Hi @Nic Brough -Adaptavist- 

Isn't it possible to write a listener that sets the resolution every time the status is changed to the final meta-status. Of course, only if the resolution isn't already set?

Can you explain what is the real reason against this approach (since Jira 2)?

Best regards, Rolf

[Nic Brough -Adaptavist-]

Absolutely, both post-functions and listeners can do that.

There's no reason not to - since Jira 2 where we got editable workflows, setting resolution as part of it has been something Jira admins (should) consider to be part of their job!