Resolution date not returning correct data

[Lydia Hawkridge]

Hi all,

Every week, I run a report for my company on all the tickets resolved in the last week. I recently noticed that some statuses which are typically "in progress" (blue) statuses are showing up in the results AND some statuses which are typically "resolved" (green) statuses are not showing up in the results.

I know there are other ways I can update the filter to show what I want but it would be more reliable to use "show me all tickets "resolved in XXX days"  if this was working correctly. 

I assume I need to update workflows but I'm not entirely sure what I'm looking for to fix it as, as I say above, the statuses as defined in the workflows at the correct stages (I think) right now?

Hopefully this makes sense. Help MUCH appreciated.

Thanks,

Lydia

[Esther Strom · Accepted solution]

@Lydia Hawkridge there is indeed JQL that would let you search that way. Here's an example; you can switch out the issuetype, statuses, and dates. You can also eliminate the From part if you don't care what the original status was, only the status it was changed to.

issuetype = Story AND status changed from "Backlog" to "In Progress" during("2021-01-01", "2021-07-01")

[Lydia Hawkridge]

Thank you @Esther Strom 

My company have a lot of projects which all run their own slightly unique workflow and have a significant number of statuses associated.

How would I update this for multiple issue types and statuses? Also, is there a way to do "changed to" rather than include the "from" to avoid having to list out all the different variations (there are about 30 - eye roll, I know). This is why historically I've tried to rely on the resolution date.

Hacked your example to show what I would want to do:

issuetype = ALL AND status changed to "Done" OR "Passed" or "Complete" during("2021-01-01", "2021-07-01")

Thank you,

Lydia

[Esther Strom]

Yup! Use the parens to pass an array of values (available for almost all fields where you want to check multiple values, not just statuses).

If you're truly trying to search for all issue types, then you don't need to search for any issue types.

status changed to ("Done", "Passed", "Complete") during("2020-01-01", "2020-07-01")

 Example of using parens for other fields:

issuetype in (Bug, Story)

reporter in (user1, user2, user3)

etc.

[Lydia Hawkridge]

ahhhh okay @Esther Strom this is what I need - thank you!!!

[Jack Brickey]

Basically this comes down to properly setting and clearing the Resolution field. You need to ensure that you set the resolution using a post function on any transition to a ‘done’ status. AND you need to ensure that you clear the resolution on any transition out of your done statuses. Otherwise issues that are no longer in a done status will show is resolved. 

alternative to the post function method is to use a transition screen which presents screen to the user transitioning to done. This allows them to select the type of resolution, e.g. done, won’t do, etc.

[Jack Brickey]

Please note that my response above was very late to the game. I had the window open editing it and then got distracted with a conversation with my spouse and eventually came back to it and submitted my answer. The world had revolved three times by the time I finally responded.😂

[Lydia Hawkridge]

Thank you @Jack Brickey this is helpful, I think you're right that I need to update the post functions for the statuses which aren't doing the right things right now. 

There are a bunch of statuses and 100+ workflows -it's a bit of a riot (not my doing) so doing this could be time-consuming / prone to holes.

Longterm, I need to clean this up.

Shortterm, I'm thinking maybe I create an automation to say, anytime a status gets updated to X (one of the many variations of done), update to status Y (original done status I know works).

Thoughts on this?

[Jack Brickey]

It’s hard to Answer the question definitively without really seeing your workflow and understanding how it works. The question really is why do you have so many done statuses. Disclaimer I have my own set of bad engineered workflows of my own doing - I own it. 

i’m struggling a bit to give you advice to be honest because I don’t want to be the wrong advice but here’s one idea.

Scratch that… I just typed a long hacky idea and I deleted it because I just couldn’t bring myself to suggest it.

The right solution is to simply attack one workflow at a time and make it right. It really won’t take much time especially if you focus on the important ones I’m sure there’s a lot of stuff out there that you just really don’t care about. Leave that stuff for another day.

[Lydia Hawkridge]

Thank you all.

For now, I am proceeding with @Esther Strom JQL:

status changed to ("Done", "Passed", "Complete") during("2020-01-01", "2020-07-01")

This solves my issue now, and longterm, yes @Jack Brickey you are absolutely right, I probably just need to " simply attack one workflow at a time and make it right". The multiple workflows and statuses are not my doing I hasten to add! They are a predecessor of LOTS of different project managers over the last decade running things the way they wanted to and no central person ever overseeing/managing it. I'm slowly but surely trying to regain some centralised control - there's just a lot :)

[Lydia Hawkridge]

Sure @Bill Sheboy 

It's:

resolved >= -7d ORDER BY created DESC

I am using what appears to be the OOTB resolved by filter?

If there is a JQL which I can use to determine:

Show me [all tickets] which were updated to [specific statuses] between [date] and [date]

That would be ideal. I don't have the JQL smarts for something like that.

Thanks,

Lydia

[Bill Sheboy]

Hi Lydia,

Yes, that query you have should work when issues are marked as resolved.  If you are seeing different results, it is possible one or more projects are not setting that value in their workflow/final status.  Definitely something to check with your admin(s).

To query this the other way you noted, you could use something like this:

project = myProject AND status WAS IN (statusA, statusB, etc.) DURING ("date1", "date2") ORDER BY Key

or another way to see the "done" issues from last week (note the -1 values) is:

project = myProject AND statusCategory = Done AND statusCategoryChangedDate >= startOfWeek(-1) AND statusCategoryChangedDate <= endOfWeek(-1) ORDER BY Key

Please look here for more information about the operators:
https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-operators/

__Bill

[Esther Strom]

Slight clarification of the "was in... during" JQL. This will give you all tickets that were in any of those statuses during the date range, but it will not tell you if the tickets were actually *moved* to those statuses during the date range - they could have been in that status for a year prior to the start of the range.

If you're truly trying to find tickets whose status was changed during a specific time, you'll want to use the "status changed to... during" format I showed below.

[Lydia Hawkridge]

Hi @Bill Sheboy 

Thank you for your suggestions.

I am the admin - but I can't seem to see what is missing from the workflow. When you say "are not setting that value in their workflow/final status". How would I go about checking this, where would I set this value?

[Esther Strom]

It depends on your project setup. Assuming you're using company-managed projects, and that your boards are not set to allow simplified workflow (which automatically sets the resolution when a ticket is dragged to the rightmost column), you'd need to edit the workflow transition to Closed, or whatever your final status is. 

In your project, go to Project Settings, then to Workflows. Click the pencil icon to edit.

On the workflow edit page, choose the final status (in my example it's Done).

Then go to the Postfunctions tab and make sure there's an entry to set the resolution. 

As Jack and Bill mentioned, you'll also want to update the postfunctions of transitions to other statuses to remove the resolution; if it's not already there click the Add Post Function option and use the Clear Field Value option. When you're done, publish the draft to make the new workflow take effect.

[Lydia Hawkridge]

Thank you @Esther Strom this is really helpful. 

[Bill Sheboy]

Hi @Lydia Hawkridge 

Would you please provide the JQL you are using to run your report?  Seeing that may provide more context for the community to offer you suggestions.  Thanks!

Best regards,
Bill