We have a custom workflow with custom status - New, Open, Addressed, Closed, Rejected, Cancelled, Info Needed, Review, Monitor. I am trying to use the Created vs. Resolved chart to show the defect trend. The filter I am using is:
project in (FQG) AND issuetype in (bug)
However, this query does not show the correct data in the chart. Is there a way to use this chart to show the trend for bugs having custom workflow?
First, I'd double check and make sure you're loading the correct filter name in the gadget. If you have many filters that are similar in name, you could be loading in the wrong filter.
Second, we use a filter very similar to yours. Here is the filter we use for our metrics:
Project = FQG AND type = Bug AND (resolution = Unresolved OR resolution = Fixed)
We don't care about alternate resolutions such as; won't fix, duplicate, etc. So we filter them out and only look at the unresolved issues, and resolved issues that were actually fixed. Any other resolutions will just inflate your numbers.
Third, launch your filter in the Search For Issues view. Actually look at the issues and resolutions being returned. You can change your view to List View to assist with this, and make sure the search results for your filter are exactly what you want them to be.
The gadget is fairly straight forward. You create a filter of choice, save it, and load it in with the settings for how you want to consume the information.
David, your answer helps me. But our problem is that the value in the Resolution field remains Unresolved no matter what the bug status. I did some online research and saw that because we have a custom workflow, we need to add a transition, though it is not clear where to add the transition.
I guess my question now is, how do we make the resolution field change its value when the bug moves through the various transitions in our workflow.
I see. In your modified workflow, you didn't add "resolution" field to a transition step. This subsequently resulted in none of your issues getting a value entered into the "resolution". JIRA then doesn't see any of your issues as being resolved.
There are a few things you will need to do to correct this.
For Step 1: Every ticket that ever get's closed, should have a resolution. This means every workflow step that leads to Closed needs to have Resolution present in that screen, or have a Resolution set prior to the Closed status in the workflow.
For every transition leading to closed, modify that screen by adding the Resolution field to it. JIRA hard codes the resolution field as required, no matter what. You will need to make sure that any other transition in your workflow uses a different screen for updating or editing issues, or you will be marking every issue as resolved too early.
The shortcut to get to your Screens is (g+g, type in Screens). This link should help you out with how to edit screens.
For step 2: If you reopen issues... on that transition, go to the Post Function, and add a function that clears the Resolution field. Jira will see the reopened issue as unresolved.
For Step 3: You can fix this by bulk editing, but you'll have to do a few things. You will have to add Resolution to the screen that displays when you edit an issue for your project (you don't want Resolution on your edit screen, so be sure to remove it after you're done). You will then need to enable the ability to edit closed issues. This can be found here. Once that is done, simply bulk edit your issues to add a resolution of your choice, and you will then have a working gadget.
The gadget doesn't actually care much about your workflow.
That's it. No status, no faffing around with alternate resolutions, don't care how simple or complex the workflow is, it's just a plain look at when the issues were resolved for any reason.
Now, a change of resolution *usually* happens in your workflow, either by a transition screen (to set it) or a post function (to set or clear it), but all that matters is that change. You can layer other logic onto it by using all sorts of filters, but the report is really simple at its core.
Thank you very much Nic, for your wise input.
It is much clear now. It did not work for me either, as I realised with you feedback that the JIRA implementation we are using, it is not as standard as it should.
It get resolution changed only when status changes to Resolved and with a Resolution date filled!
Then, is it correct that a simple rule as changing resolution were resolved, no matter, if canceled, closed, or resolved final statuses, will make possible to use this gadgect, right?
I wonder if there is a checklist or similar, where I can find the standard rules for making possible to use standard Jira gadgets... do you know?
Thanks in advance,
Yes, it's just a simple "if resolution is set, it is resolved" rule.
I am not sure if there is a lot more you need to know about other Jira gadgets, once you get "resolved is not empty = resolved", the gadgets just report on the data you have added to Jira.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs