list of sub-tasks shows refused issues as green

Christopher Yeleighton November 30, 2015

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
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 30, 2015

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.

Christopher Yeleighton November 30, 2015

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 30, 2015

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.

Christopher Yeleighton November 30, 2015

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 30, 2015

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.

Dave Furlani April 29, 2019

We have a status of Rejected for our review sub-task. 

The parent still shows the sub-task with a tick, and with a green status name, but at least Rejected looks different to Done so it's more obvious to the user that all is not well for the parent task. The workflow transition to Rejected also sets the resolution to Rejected.

I think that in the parent workflow you can use conditions on the sub-task statuses to stop the parent task from showing the transitioning to Done.

0 votes
Christopher Yeleighton November 30, 2015

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?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 30, 2015

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
TAGS
AUG Leaders

Atlassian Community Events