list of sub-tasks shows refused issues as green

Is there a way to make issues that are DONE but not Fixed (e.g. refused, invalid or whatever) to show a RED marker cross instead of a GREEN marker tick?  The status DONE should be red too.

2 answers

1 accepted

0 votes
Accepted answer

I'm afraid not.  The flag is very simple -  a green tick for "you don't need to worry about this any more" if the resolution is set.  Doesn't matter what it's set to, it's resolved, so it's done.

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 sad

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.

But the work flow does not offer the required identification of sub-tasks, it can only prevent you from resolving the parent, right?

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

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

227 views 6 0
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you