When a tester creates a new bug to the status "To Do", it's automatically set to resolution "Unresolved". Is it possible to create other resolutions set to auto- change when bugs are set to other statuses? For an example, Status of the a bug is "Closed", then resolution would become "Not a bug".
Resolution is used within each of our project's overview (How many bugs are unresolved per person, how many bugs are open, etc). What is difference between "Resolution" and "Status"? Do you need to use "Resolution"?
Thank you for your time and assistance answering my questions, any thoughts would be greatly appreciated.
PS: I'm using JIRA on demand (cloud).
Yes, you need to understand how JIRA uses the "resolution" field, and you do need to use it. It is a display for the user to say "why we have finished with this issue and are not going to do anything else with it". But it does more.
Status is not really a field, it is an indicator to tell the user where an issue is in the process. But the status itself has little to say about whether an issue has been dealt with and you don't really want to do anything more with it. Even if you call a status "closed", "ended", "done", "rejected", etc, that does not tell JIRA that the issue is ended.
That is what Resolution does. In database terms, Resolution is a field on all issues. If it is empty then then JIRA treats the issue as "open", and displays unresolved on the issue. If it has any content, then JIRA treats it as "done", dropping it from "stuff we need to do" reports, striking out the issue number in many places, putting ticks next to them on sub-task displays and so-on.
You need to be aware of that when you are working with workflows. If you look at the default workflow, it does two things that you'll need to think about - it has post-functions on "reopen" transitions that clear the resolution (note - not "set it to unresolved", but actually empty it out), and it has a "resolve" screen on transitions that go into status that you want to treat as "closed". The resolve screen contains the resolution field, so it gets set when the transition is used. The third thing you can do is explicitly set it with a post function (e.g. if you have a transition for "reject issue", then instead of asking the user to set "rejected" as the resolution, it's easier to set it for them)
Even if you choose never to use resolution, you should still set/clear it in your workflow. Or JIRA will show "closed" issues as still needing attention, whatever your closed workflow status are.
Just a quick recap: Status is a way to represent the ticket's current state. Examples: Open, To-Do, In Development, In QA, Client Approval, Closed. While the Resolution is a specific description of a resolved/closed ticket. So if a ticket has been moved to Closed but the bug that was reported isn't a bug - we'll set the resolution to "No a Bug", as you have mentioned. Other possible examples: Duplicate, Fixed, Can't Reproduce...
It's preferred to use a Resolution when closing tickets to provide another layer for reporting later on. For example, this will enable you to scan how many bug tickets were actually fixed vs how many were duplicate. This can be done by simple JQLs:
project = x and issuetype = bug and status = closed and resolution = duplicate
project = x and issuetype = bug and status = closed and resolution = fixed
You'll need to make sure the resolution field appears in the transition screen when a user is closing an issue, and can add more resolutions here: <your domain>/secure/admin/ViewResolutions.jspa
Edit the workflow, find all the transitions going into "closed" and edit them - there's a field for "screen", which you'll find is currently empty. Set it to the screen you want to use (use the standard resolution screen as an example, but you'll probably find you want your own screen with other fields - you can add your own screen and just put "resolution" on it to begin with)
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot