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:
I would prefer these to be setup as follows
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.
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.
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.
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.
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...
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...
These 2 events trigger the issue to become Resolved/Unresolved.
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.
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.
To answer “How scrum works,” most of the teams I've worked with first addressed the question: “where to start?” That question applies to both implementation and improvements on the Scrum framew...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs