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