Created Vs Resolved Chart not capturing Resolved issues

[Sunitha Chellathurai]

The report is not capturing the Resolved issues in the chart

[Nic Brough -Adaptavist- · Accepted solution]

My guess is that your issues are not being "resolved".

The status you are seeing here says "resolved", but that is the status, which is not what Jira uses for this chart.  This is looking at whether the issue is "resolved" as defined by whether the Resolution field has a value or not.  If it is empty, the issue is unresolved, if it has any value set, then the issue is resolved.  (Technically, last time I looked at the code, the gadget actually reads for the date that the resolution was set, but that's empty when the resolution is empty)

I suspect your workflow is not setting (or clearing) the resolution where it needs to

[Sunitha Chellathurai]

Thanks, Nic...Now able to see the Resolution reflected in the Report. 

Suggestion: As I see so many have ended up asking the same query, JIRA must be enhanced to mention the basic details when the dashboard is chosen. 

[Ashish Mehra]

@Nic Brough -Adaptavist- I have a similar issue on the chat and I am not able to understand what do you mean by "resolved".

In my workflow, the ticket is moving from various statuses to "Done" or "Duplicate" status. I have added the general comment screen in the transition. This is the exact same thing I have done in other projects, and the created vs resolved chart works, but it does not work in the case of one specific project.

[Nic Brough -Adaptavist-]

Does your "general comment screen" include the resolution field?   If it does, then I am worried about the "general comment" - you really do not want the resolution field on any screens except "the screen(s) used in close transitions"

That's all that matters to the chart - if the resolution is set or not (and when, if it is set to something)

I'd bet that in your one specific project, you are not setting the resolution on the close transition.

[Marc Isikoff]

To be sure, we have issues with the system field Resolution set to "Done", our status is "Resolved", and we have TTR SLA data that is correct. So these reports are not based solely on the system field Resolution else we would have Resolved issues in reports.

These reports use a system field: Resolved which is a date field collected by Jira when you use their resolution screen to give a resolution. This is common on Projects but not common in Service Desk, because we do not use a Kanban or Sprint board thus do not have that form and frankly adding that form to the workflow is a step backwards from just having a status of resolved.

I cannot understand why Atlassian makes a fairly straight-up normal report and puts in constraints we cannot edit and renders the report baseline useless.

[Kateryna_v_SaaSJet_]

Hi @Marc Isikoff 

This is a pretty common problem for Jira users. As Nick suggested, you should first check what conditions make "Resolution: Set" and then check the field's value in the ticket. Then, set the required values in the tickets, or if your problem persists, you can use the alternative solution — the Atlassian Marketplace apps.

For example, you can try the SLA Time and Report add-on for Jira (developed by my team), where you can set all resolution conditions for SLA conditions and select the Resolved status in reports (and many other filters).

In this case, the application will be more convenient and understandable. Plus, it's free for up to 10 users team and has a 30-day trial, so you can try it.

[Marc Isikoff]

As per Nick's advice, we have resolutions being set to "Done" and those are the system field "resolution" which shows on each issue as Resolution: Done and a customer status of "Resolved". This is why I said Atlassian messed up these reports because they focused on everyone doing things one way with little freedom to innovate.

We are finding Atlassian in general has the wrong strategy as many large firms will not deploy to their cloud (but they will deploy server version to our own) nor allow marketplace apps as bolt ons.

As such, this will not work for me/us as we cannot use Marketplace add ons.

[Nic Brough -Adaptavist-]

That's not the case, you seem to be mixing up Resolution and Status.  They are two totally independent things, despite almost every human Jira user effectively tying them together, often by simply adopting Jira's defaults.

There are two ways Jira recognises an "ended" issue.

In both cases, the point of an ended issue is that "it needs no more attention". 

In plain Jira, this is a simple objective binary flag for all users who might look at an issue.  In JWM, JPD and JSM, the status is irrelevant, all that matters is the resolution.  If the resolution is empty, the issue needs attention.  If it is filled (even with values like "unresolved" or "needs work"), the issue is ended (done/closed/flagged as a duplicate/cancelled, whatever)

In Jira Software, "ended" is subjective.  The resolution is irrelevant, it's the status that matters, because it determines which column on the board an issue is in.  Jira only recognises the last column on a board as "done", meaning "ended", so an issue is done if it lands in the last column.  However, one team's "done" might be another team's "to do".

For example, a development team's board might have "dev complete" in the last column, but the operations team has "dev complete" in their "to do" column.  An issue in that status is "done" for the developers, but "needs work" for the Ops team.

So, the TLDR bit: for a report to work on resolution, you need to set it at the right points in your overall workflow.

If you're not using Software boards, that's going to be quite easy to do - set a resolution when going into a "done" status, either by

• Having a post function that sets it
• Popping a screen with the resolution field on it (it is not mandatory, but you can not leave it blank when it is offered, so your people will have to set it)
• In some boards, you can tick the "this status should also have a resolution" flag under the column

And, of course,

• Put a post-function to clear the resolution on all the transitions from your "done" status back to any "not done" status

[Marc Isikoff]

Nick, yes this whole issue is based on the Resolved field (system date field) which ONLY gets filled if you use a board with a Done pop up to enter a Resolution (system field) at which time the Resolved date is set.

They let us update Resolution (system) field in Automation but they do not allow Resolved (system) date field to be set. And natively you can add approvers and steps in workflow needing approval but you cannot add the resolution screen (the one we need for selecting system field resolution and having it fill resolved) natively in workflow.

The options you mention (post function, popping a screen, use a board) are not accessible to project admins where I work hence we rely on Automation rules having access to system fields. We do not have a board for our JSM either as we work the tickets in JSM, not a board.

[Nic Brough -Adaptavist-]

That's not how it is working.

There are many ways to set a resolution, and when you do, the "resolved" field gets set.

You can not set the resolved (date) because Jira calculates it from the date/time stamp you resolved the issue.

It sounds like the problem you might have is that your admins have made a mistake in defining your workflows (I'm not sure why you say "you cannot add the resolution screen" because you can, for example) but that is very much a guess.  Boards are only one way to work, Jira gives us several.

I do not like the way resolution works in Jira, it's not the clear and absolute flag it should be, so I'm quite "animated" when I'm talking to people who might be about to edit a workflow and they don't start with asking the question of "are we there yet?".  Never edit a workflow until you know what all the status are and how they map to "done" or "not done".

[Marc Isikoff]

Nic,

I can say concretely that the Resolved (system date field) is NOT being set when we update the resolution (system field). 

The issue is that we want to capture some text from our support personnel so we have a custom text field "Resolution" and when they progress a ticket in the workflow to "Resolved" (a status we have), our automation checks to see if they supplied an entry to their custom Resolution field, and if so we set the Resolution (system field) to "Done" and the Resolved (system date field) is not set.

Hence why I say the issue is the Resolved field as it is not set just because the Resolution field is set and/or the issue progresses to a certain status. We do know that on a project board, if you drag a story to Done it pops the resolution window and then supplying the reason and saving does set the Resolved field.

[Nic Brough -Adaptavist-]

Not how it works on any of my Jira installs, cloud, DC and Server.

The best think you could do is stop having a duplicate resolution field.

[Marc Isikoff]

That's not too helpful for us. For one, you can have many duplicate fields because there is only one system and the rest are cf#s. This is no different than any other field in terms of having dupes.

At many smaller businesses, Jira admins have full control, and can do things like add a post function to handle this. This is not the case for many large, Fortune 10 companies.

I have had experience at other F10s and regardless, this is how Jira works. They made a modal window when you have a board so fire up when you drag a story to Done. It makes you put in a resolution and then that modal window does the system field resolved date update.

Failing that in Jira Service Management, which has no board, we cannot add that modal window to the workflow. Nor can we add a post trigger to the workflow.

So we are stuck with being able to populate the system field for resolution, just not the system resolved date (thus cannot make an issue fully resolved).

[Nic Brough -Adaptavist-]

I can't offer more help.  You need to do two things:

Start using the system resolution properly.  You need to look at your workflows with your admins and get them to set and clear the resolution at the right place in the workflow, either with a screen, a board setting, or a post-function (don't use more than one of them - a post-function will override what your people put on screens)

Get rid of your duplicate fields, they are making a nonsense of your issue tracking (if there was one change I would make to Jira as it is now, it would be to re-implement the code that says "you can not create a field with the same name as an existing one")

You can implement this in JSM projects, despite having no board, and you can add post-functions to the workflow, although you may need to swap to the "old" workflow editor.

[Marc Isikoff]

Thanks Nic - though agree to disagree on the dupe names. I might need 'Environment' to be "Dev, UAT, Prod", while someone else might need Environment to be "Sandbox, Dev, ProdTest, UAT, Prod" but that is why they give differing cf #s for those. Doesn't really cause problems at my company, but to each their own.

[Nic Brough -Adaptavist-]

Duplicate field names are a nightmare for anyone trying to use them.  Reporting fails, this sort of problem you're having with the resolution is intensely confusing, and even similar names will cause you problems (do not have more than 5 fields with the word "status" in their name if you want any useful reporting)

You can have different option lists for fields by having different contexts for the same field.