Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

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

Why doesn't the Created vs. Resolved report see Resolved bugs

I am simply using the default workflow that comes with a brand new Jira 4.4.1 install. When I create a bug, move it to in progress, then to Resolved, the Created vs. Resolved chart does not pick up the resolved bug. Nor does moving it to Close.

What am I missing?

1 answer

1 accepted

1 vote
Answer accepted

Are you setting a resolution when resolving it?

Ahh, no I am not. Is that the trigger for the report/dashboard gadget getting updated?

Interesting if so, as it was not part of the Resolve screen in the default jira workflow :-)

Ah, that would be it! Yes, there's a couple of tricks going on behind-the-scenes here.

First, Jira has this concept of resolved/unresolved based on the setting of a resolution, independent of the status of the issue.

Second, Jira 4.0 and above have a built-in "resolved date" field. In older versions of Jira, the charting plugin provided it, but that's been (rightly) absorbed into the core distribution, and it's that which drives the report. The trick here is understanding that it's set when the resolution goes from null to not-null (if it happens more than once, it looks at the latest time it happened).

It becomes a bit of a pig to explain to my users, but I put that down to my explanatory skills, as they all go "ahh, I see" once I manage to get the right words for them.

As an aside, the Resolution is part of the resolve screen in the default Jira workflow (Atlassian wouldn't distribute Jira without that - it wouldn't look too clever having a whole "resolution means you can stop worrying about the issue" system and loads of reporting based on it and then distributing an off-the-shelf system where it didn't work). But it's dead easy to remove by editing the screen or hiding it in the field configuration - I suspect your org has accidentally done one of those without realising. FWIW, I'm happy to hide resolution for a lot of projects, but then I make heavy use of "set/unset field" in workflow post-functions to make sure the users see the "right" resolution for each of their workflow steps.

Nic, thank you very much for the explanation. I am constructing my workflows now, and for some reason missed that in the default Resolve Screen.

The other thing that your explanation answers is why the resolve date was not getting updates for resolved bugs I have done test imports for from our old bug system (Team Tracker, I was doing CSV imports). Basically, there was no equivalent "Resolution Field" in Team Tracker, just "State" (Status in Jira). So my imported Resolved bugs from the Team Tracker csv had a resolved date, but no resolution string, hence the Jira Resolution values were <null>, since I wwasn't even matching it with any Team Tracker field!

Awesome, definitely an "Ah-hah!" moment in my Jira knowledge (which is all but about 2 weeks old..).

Thanks again,

-Brian

Glad to be of help! One of the main reasons I post here is because someone on the forums (Neal, we miss you!) took the time to explain the resolution stuff to me, and I try to give back when I can.

Hey, how come I cannot make the Resolution field "Required" in the Field Configuration?

Heh, it's because it's an odd field.

You can't, and shouldn't, make it required (like the other fields anyway). I know exactly what you're thinking, and you're right. But when Jira makes a field mandatory/required, it's an all-or-nothing proposition - the field is mandatory on creation of the issue and then throughout it's entire lifecycle. That breaks "resolution" completely, because you really don't want to create issues that are resolved as soon as they're written up (ok, ok, edge cases, I know, it's valid for historical recording etc).

Atlassian have compensated for Jira's failure to allow fields to become mandatory part-way through the lifecycle by assuming that "when resolution is on a transition screen, it has to be set". It's not actually mandatory on the resolve screen, but the way it's been implemented, the users can't go through the transition without setting it.

(I hope that makes sense - I'm well aware I've been doing this for years and may not be explaining it too well any more)

Nevermind, looks like once I add it to any screen, it becomes required (red *). How come though Field Configuration does not reflect its Required nature?

Suggest an answer

Log in or Sign up to answer
TAGS

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