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 ?
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.
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".
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.
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.
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?
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.
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.
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.
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.
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
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
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