Today I found an issue on our board that was a duplicate of another issue in the backlog. I commented saying "this is a duplicate of FOO-22, closing". I dragged this issue to our "done" column.
What is the recommended way to mark issues as duplicate, stale, wontfix, etc.?
Just leaving a comment stating that the issue is a duplicate does not seem like the best solution.
I'd love some advice.
Interesting. Thanks for quick reply! So, the resolution feature is the best way to handle this? Do you have your resolution tied into a workflow, or do you manually pick a resolution when you move an issue around your board?
The resolution field should ONLY be shown on transitions because it is required when shown. I usually put a transition to closed from open to handle the the duplicate or won'tfix cases. The OBE and won'tfix reason are often used further into the workflow, usually from a status where research into the problem is being done. Or you can have it at the end and just run the issue through the workflow and close it with OBE or Won'tfix
Great info! Looks like I need to dust of my workflow tweaking skills. Last questions, does your workflow account for those rare occasions where you re-open an issue? It's been a while since I played with our workflows, so, I'm not sure if this would help me or not … But, are you able to share a screen shot of your workflow? No worries if that's asking too much, I totally understand … I just think it would help me to see the workflow in its graph form. Maybe you could add it to your answer? I'm sure other folks would also find it helpful to see a visual example. Again, no worries if that's not an option for you, I completely understand. Thanks a again, I really appreciate your pro help!!!!
Yes. I only allow the project admin to reopen issues and have a select field with a few reasons like Closed Wrong issue (it happens more than I like), New Information, Other. You can add any more that often come up. I also have a required text field, Reopen Comment, they need to explain in more detail. Don't forget to CLEAR the resolution field in the post functions. I also have a select field named Reopened with a default of No that is set to Yes in the post function. That makes it easy to find issues that have been reopened. I restrict who can reopen because I've found people recycling issues for new work of the same type, which skews the data on how many issues are worked. You could create a user role of Reopen and put people like the lead developer or other folks you trust and limit the transition to that role instead of the project lead. But you want to limit it.
when project uses Agile Simplified Workflow you actually will not see Resolution field because there are no transition screens.
For this case use different terminal statuses instead.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events