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

Brian Cohen October 3, 2011

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
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 4, 2011

Are you setting a resolution when resolving it?

Brian Cohen October 4, 2011

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 :-)

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 4, 2011

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.

Like Kalai likes this
Brian Cohen October 4, 2011

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 4, 2011

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.

Brian Cohen October 4, 2011

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 4, 2011

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)

Brian Cohen October 4, 2011

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