Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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 ?

1 answer

1 accepted

1 vote
Answer accepted

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

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".

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...?!

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.

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....

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.

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

Like Rolf Lader likes this

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.

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"

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

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.

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.

Like Mick van Breukelen likes this

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

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!

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

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...

167 views 6 7
Read article

Community Events

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

Events near you