Is there any way to modify the built in filters used on a projects Issues dashboard? On a projects issue dashboards the default filters are setup with: * Unresolved: By Priority * Unresolved: By Assignee * Unresolved: By component * Unresolved: By Issue Type I would prefer these to be setup as follows * Unclosed: By Priority * Unclosed: By Assignee * Unclosed: By component * Unclosed: By Issue Type I realize the Status Summary shows Resolved issues, however, the other areas of this dashboard essentially hide the Resolved issues. IMO, hiding the resolved issues from the dashboards makes it less usable for QA and Project Managers I have created custom dashboards to show Resolved issues how I want, but it would be nice to have this functionality on the default Issues dashboard. Thanks, J

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Project Issues Dashboard - Closed vs Resolved Filters

Joseph O'Neil

Is there any way to modify the built in filters used on a projects Issues dashboard?

On a projects issue dashboards the default filters are setup with:

Unresolved: By Priority
Unresolved: By Assignee
Unresolved: By component
Unresolved: By Issue Type

I would prefer these to be setup as follows

Unclosed: By Priority
Unclosed: By Assignee
Unclosed: By component
Unclosed: By Issue Type

I realize the Status Summary shows Resolved issues, however, the other areas of this dashboard essentially hide the Resolved issues. IMO, hiding the resolved issues from the dashboards makes it less usable for QA and Project Managers

I have created custom dashboards to show Resolved issues how I want, but it would be nice to have this functionality on the default Issues dashboard.

Thanks,

Accepted answers

Ramiro P

Hi Joseph, I think the main problem is that the difference between an unresolved issue and a resolved one is the resolution is empty clause and you don't have this field difference between an 'unclose' and a close issue.

There's no much you can do since you are On Demand a version, but with a good filter and a gadget like the bidimensional table you can have some good statistics on the dashboard.

It all depends in how you use the Resolve status with the QA group.

Cheers

All comments

David G

There is no means through the UI of modifying the filters or gadgets on the Project's Issues screen.

You can however change where the 'Resolved' flag if flipped in your workflow, so that it occurs after your QA process has signed off on an issue. This will keep the visibility of issues on your Project's Issues dashboard, along with the 'Assigned To Me' default gadget, until after the QA cycle. Sames goes for every other gadget out there that is based on the 'Resolved' flag.

HOW TO:

The trigger you are looking for is the EVENT that fires during a transition Post Function. The default transition name of the JIRA workflow is Resolve Issue, which is available for the In Progress status. It has a Post Function called...

"Fire a Issue Resolved event that can be processed by the listeners."

This is the event that triggers an issue to become 'Resolved', and all of the corresponding filters are based on this event. If you Edit this event to another type, such as 'Issue Updated'. it will stop that flag from occurring when Dev finishes with the issue. You will need at add this event type back in after QA has signed off on an issue.

The opposite event that triggers an issue to become 'Unresolved' is called...

"Fire a Issue Reopened event that can be processed by the listeners."

These 2 events trigger the issue to become Resolved/Unresolved.

Steps:

Log into JIRA with an admin account
Enter Admin mode
Browse to Issues > Workflows
1. Or use shortcut: g+g workflows
Make a copy of the workflow you intend to edit
Open the copy workflow via the Edit link to the right
In the Diagram view mouse over the blue 'Resolve Issue' transition
L-click the cog-wheel and select View Post Functions
Scroll to the bottom where it states Fire a Issue Resolved event..., select Edit
From the drop down, choose a different event type. Ex. Issue Updated
1. NOTE: These events trigger notifications, based on Notification Scheme when this transition occurs. You can even create your own custom events
Go to the place in your workflow where you want the 'Resolve' flag to trigger after QA, perhaps where they Pass an issue
L-click the cog-wheel and select View Post Functions
Scroll to the bottom where it states Fire a Issue <something> event..., select Edit
From the drop down, select Issue Resolved
Now that we have our 'Resolved' event back in our workflow, we need to put in the 'Unresolved' event in.
1. By default, the Reopen Issue transition (screenshot above) has the Issue Reopened event already
You will need to place the Issue Reopened even in at every location past the Issue Resolved event where an issue can jump back up the workflow

Attached below is an example workflow that is used by one of our projects. Because on this project, any business user can submit issues, we have an issue triage bucket where the Business Analyst and Project Owner can prioritize and assign issues to sprints/devs/backlog.

Business Analyst & Project Owner work in the New and Request More Info status.
Dev works in the Open, Reopened, and In Progress status.
QA works out of the Resolved status, either Reopening an issue that fails testing, or passing the issue forward for scheduled testing by the Busienss Users/Owners.
Business Users/Owners can pass issues (which flags them as Resolved), or fail issues and send them back to QA for review.

This means the 'Resolved' flag doesn't trigger until after Dev, QA, and the Business Users have all completed their sign off on an issue.

Ramiro P

There's no much you can do since you are On Demand a version, but with a good filter and a gadget like the bidimensional table you can have some good statistics on the dashboard.

It all depends in how you use the Resolve status with the QA group.

Cheers

Joseph O'Neil

That's essentially what I ended up doing is creating filters and my own dashboards to ensure the resolved issues have visibility.

Using the default workflow, it seems that an engineer would mark an issue Resolved and specify a Resolution. However, the issue isn't closed until QA closes the issue or reopens the issue. All of the built in filters on the project dashboard treat Resolved too similar to Closed. IMO, until issues are Closed they should be shown in this view.

My goal has been to not create custom workflows unless necessary and I'll probably just work with custom dashboards for now.

Oh well, thanks for the response.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

project

cloud

jira-cloud