Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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
Answer accepted

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.

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.

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
TAGS
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...

296 views 9 7
Read article

Community Events

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

Events near you