Created vs Resolved Gadget

[Elif Alverson]

Hello, 

I would like to use "Created vs Resolved" gadget in our dashboard. Unfortunately this gadget does not show the accurate numbers of the issues. 

First, I added Resolved "none" as resolution status to see if I can see the resolved issue numbers since all I saw was " 0". Yes, that fixed one side and broke another. Now all the issues with resolved " none" statuses count as resolved eventhough they are not resolved yet. So this gadget counts all the issues with resolution status does not matter if the status is none or done.

What is the fix here? How can I have a report which shows the correct count of issues created vs. resolved? Thank you.

[Nic Brough -Adaptavist- · Accepted solution]

It is accurate.

It is showing all the resolved issues as resolved and all the created ones too.

The problem is that you have created a broken resolution.  Your "none" resolution means the issue is resolved.

Resolution is only unresolved when it is empty.

You need to

• Rename "none" to "do not use"
• Go fix your usage of the field
• remove it from all create and edit screens, it should only exist on transition screens on transitions where you are closing the issue.
• On close transitions with no screen, add a post-function to set the resolution
• On re-open transitions, add a post-function to clear the resolution

Now that you've stopped the corruption getting worse, you should next look at all the issues that have "do not use" on them, and analyse the best way to try to get them all unresolved.

[Elif Alverson]

@Nic Brough -Adaptavist- , could you please provide me the steps for how to clear the resolution field on the re-open transition? 

P.S: I removed resolution status none. There are no issues with the resolution status none at this moment.

I assume, add post function to transition then update issue field, then select resolution to none? Is that accurate? I want to be sure since there is resolution field called none in the system.

[Nic Brough -Adaptavist-]

For each workflow, go into edit mode for it, and work through each transition that should clear the resolution.

On each one, you'll get the transition settings pop-up, which includes a "post-function" tab which lists all the current transitions.  Most will default to having 5 standard ones.

Click add and you'll be asked "which one" - use "update field", then select resolution, and then select the first option on the list, which should display "none" (there would be two "none"s in the list if you had not removed yours!)

When you save it, you should find the new post-function listed (in a default position, you shouldn't need to worry about moving it, unless there are other post-functions you've added that it might interact with).  It should say something like "The resolution will be cleared"

Save the draft, and it's all fixed!

Really glad we didn't have to run through cleaning up, it can be a pain!

[Elif Alverson]

@Nic Brough -Adaptavist- , thank you for clarifying. There was only one" none" status for the resolution filed. As always, you are a great help.  

[Joseph Chung Yin]

@Elif Alverson -

I agreed with @Nic Brough -Adaptavist- stated.  By default in Jira/JSM - Resolution field of "Unresolved" is the internal NULL value for the field.  So, your add action of "None" for the resolution status needs to be removed. Resolution field should only be populated via WF transition's post function only. 

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Joseph Chung Yin]

@Elif Alverson -

Here is what you can do -

1) conduct an advance search for all of your issues with the resolution value of "do not use".

2) conduct a bulk update and choose "Transition issues" action.  NOTE - it is important that your re-open WF transition post function do clear the resolution value.  You may also have to ensure that your current WF status of your issues already have a transition setup to your re-open WF status.

Once the action is completed, those issues resolution field value will again be set to NULL.  Lastly, it is also recommended that before you execute the bulk update process, you should also keep a record of those issues' current WF status assignment to assist you if you need to update them to the original WF status assignment afterward.

Hope this helps.

Best, Joseph

[Tim Arthur]

I appreciate this thread. Same situation here. Question: When setting up the resolution field for a project already in flight, will it magically correlate the date that the Created vs Resolved widget uses, or will it have all issues that are resolved show as a total number on the day we implemented the ideas explained by Elif above?

[Tim Arthur]

@Elif Alverson 

[Nic Brough -Adaptavist-]

No, there's no automation for historical issues that are missing a resolution (or have a bad one).  You'll need to script something that can resolve the issues, or re-open them and re-close them.  

If you do that, the resolution date will remain "the day we fixed the resolutions", not "the day we closed the issues"

[Tim Arthur]

Thank you Nic.