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,

J

[Ramiro Pointis · Accepted solution]

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

[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.

[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:

1. Log into JIRA with an admin account
2. Enter Admin mode
3. Browse to Issues > Workflows
   1. Or use shortcut: g+g workflows
4. Make a copy of the workflow you intend to edit
5. Open the copy workflow via the Edit link to the right
6. In the Diagram view mouse over the blue 'Resolve Issue' transition
7. L-click the cog-wheel and select View Post Functions
   1. 
8. Scroll to the bottom where it states Fire a Issue Resolved event..., select Edit
9. 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
10. Go to the place in your workflow where you want the 'Resolve' flag to trigger after QA, perhaps where they Pass an issue
11. L-click the cog-wheel and select View Post Functions
12. Scroll to the bottom where it states Fire a Issue <something> event..., select Edit
13. From the drop down, select Issue Resolved
14. 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
15. 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.