Jira Automation Last Resolved record >30 Working Days

[Leslie Barrett]

We're looking to determine a way to automatically report when all of the records in a FixVersion are resolved, and the last activity is => 30 Working days and the FixVersion has not been released. The current manual process looks for the following: if there is no release date and all work in the version is resolved and there is no statement in the FixVersion description of a hold and the last resolved date in the Version is 30 working days or older

[Ayça Erdem_OBSS_]

Hello @Leslie Barrett 

Keeping track of unresolved FixVersions that have been inactive for a long time can be tricky, but there are ways to streamline this process. You can approach this challenge in two ways:

Option 1: Manual Filtering with JQL

A quick way to filter FixVersions based on your criteria is to create a JQL query that includes only issues within a specific FixVersion. This filter ensures that all issues are in a Resolved state, excludes FixVersions with a release date set, and filters out those with a “hold” statement in the description. Additionally, it checks whether the last issue activity occurred 30 or more working days ago. You can save this query as a filter and display the results in a Jira dashboard for easy tracking

Option 2: Automated Tracking with Timepiece - Time in Status for Jira

For an automated and data-driven approach, you can leverage Timepiece - Time in Status for Jira, developed by my team at OBSS, to efficiently track FixVersions that have remained unresolved for too long. Below, I’ve outlined how you can set this up using Timepiece to streamline your tracking process.

Filter Issues by FixVersion

• Use the same JQL filter to include only the relevant issues in the FixVersion.
• Apply this filter within Timepiece to ensure all reported data is focused on the correct set of issues.

Generate a Last Transition to Status Report

• JQL Filtering: Assumes that you have prepared the type of issues you want to filter.
• Report Type: Listing issues in the Last Transition to Status report.
• Criteria: Issues where the difference between the Last Transition to Status Date and the Resolution Date is at least 30 days or more.

image shows basically how to get a status duration report with your specific JQL

This report helps identify unreleased Fixversions where all work is completed but no activity has occurred for the last 30 working days.

By setting this up in Timepiece- Time in status for Jira, you can automate the detection of inactive FixVersions and reduce the need for manual tracking. 

If you'd like to explore this solution further, feel free to check out Timepiece on the Atlassian Marketplace or schedule a demo with us for a walkthrough of the app's features.

Hope it helps

Ayça

[Bill Sheboy]

Hi @Leslie Barrett 

What have you tried thus far to solve this need?

If you have rules that are not working as expected, please post the following to provide context for the community to help:

• what should happen when the noted conditions are met,
• what type of project is this (e.g., company-managed, team-managed, etc.), 
• an image of your complete automation rule in a single image for continuity,
• images of any relevant actions / conditions / branches,
• an image of the audit log details showing the rule execution, and
• explain what is not working as expected and why you believe that to be the case.

If you have not started the rules yet, I recommend trying to do so.  Successfully using automation rules requires learning and experimentation.  To get you started on creating your rule, please refer to these documentation and example sources:

• https://www.atlassian.com/software/jira/guides/automation/overview#what-is-automation
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/
• https://support.atlassian.com/jira-software-cloud/docs/use-advanced-search-with-jira-query-language-jql/

Additionally, a scenario like this could use the scheduled trigger to check resolved issues, and their siblings assigned to a Fix Version value.  It can only be solved if there are fewer than 100 issues in the conditions to be checked, and for each, there can be no more than 100 issues linked to a specific Fix Version...this is assuming also that each issue has one-and-only-one Fix Version value.

Kind regards,
Bill