Is there a way to make issues that are DONE but not Fixed (e.g. refused, invalid or whatever) to show a RED marker instead of a GREEN marker ? The status DONE should be red too.
Even if I block the transition of the parent, I am still missing the possibility to quickly identify the offending sub-tasks (not setting the resolution is not an option because it would be too much of a nuisance to have them open all the time). Isn’t it fairly obvious that a sub-task can have 3 states: done, to do and cannot be done? Of course, the state cannot be done has no place in the ideal world—but this world is far from being ideal
It might be useful for some ways of working, but most people would still regard "can't/won't" as resolved. In fact, most of us would do that with the workflow if we needed to have that ready identification. Not because it's the wrong thing to do (it is not wrong), but because JIRA does not do that. The whole of JIRA is coded for a simple open or closed meta-status, and it makes that choice based purely on whether resolution is filled or not.
It can help with the identification. If you have a workflow *for the sub-tasks* that goes something like "open" then has "closed" and "can't do it" type status, you can show the sub-task status on the parent issue. You could also just show the resolution on there too.
It matters because it can affect how the parent task’s resolution, meaning that you should think twice before resolving a parent task when any of its dependent tasks are not resolved as Fixed. In particular, when a sub-task is resolved as Incomplete, maybe you would like to revisit and re-evaluate it?
No, sorry, when I said "it doesn't matter", I meant in the code. JIRA does not care what the resolution is, just whether it is set or not. If an issue has a resolution set, it is done. That's the end of the story. You could have a resolution called "unresolved" if you wanted to and that would still represent a "resolved/done/closed/ended" issue because the resolution is set to something (don't, it's horribly confusing for the users). The value does not matter to JIRA. In the scenario you describe, I'd look at a coding conditions for the parent issue that look at the sub-task resolutions and block parent transitions when they're inappropriate. Or not setting resolution on the subtasks at all when the sub-task needs more work before the parent can be dealt with. But this is business logic, not JIRA.
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 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