You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
You are looking for a "Condition" script in the "Close" transition of the parent issue to check if all sub-tasks are closed.
It's usually the other way around you don't actively stop something, you block it. In this case, you want to do nothing, not "force a task not to close". You just don't transition it it when you don't want to close it.
JIRA has conditions on workflows that are there to block actions - a very popular one is "do not allow close when the issue has one or more subtasks in status (open, in progress, held, blocked, etc)". I suspect that's the one you need.
I'm actually partial to using a validator here, not a condition; the condition hides the "close" transition, but the reason is not readily apparent. That can be documented, trained, etc, but a validator gives you the ability to verbosely explain why the operation is not permitted. Having said that, I'm currently using the built-in condition, because there is no similar built-in validator, but I plan to write the validator in the future because I get a "why can't I close issue X" question once or twice a month. Also, it's worth noting that this condition is not enough if the goal is to fully prevent the (invalid) combination of there being a Closed parent with Open sub-tasks; you also need to add conditions to "Create" and "Re-Open" to prevent adding-or-reopening subtasks against a closed parent. This can be done with the simple scripted condition: issue.parentObject == null || issue.parentObject.statusObject.name != "Closed"
Actually, on "Create Issue", that's a validator, not a condition, as you can't put conditions on "Create". I plan to change the "Re-open" condition to a validator as well, for the reasons cited above. In fact, I think I'll do that right now :).
That's true, this is a case where you want the feedback for "why can't I do this". There is a balance though - if you do it with a validator, then you replace "Why can't I close..." questions with "Why did it let me go into the close screen without telling me I couldn't do it..." questions.
Indeed; I struggle with that one on Create in particular, since it could be a hassle should they not be able to resolve the validation issue readily in another tab. For that reason, I'm thinking automatically re-opening the parent task is the better approach for this specific case. Then again, they can just open the parent in another tab and re-open it, so I guess it's not a big deal. However, this does suggest that JIRA should have both a pre-validator and a post-validator, where pre-validators fire before the form is displayed, and would be used for cases where the criteria cannot be met within the transition's form. Post-validators would behave the same way as the existing validators, and would be used for cases where the result of the validation could change based on the form's input.
Re-opening the parent is a good option too. Pre-validators is something Atlassian shut down a long time ago - they were seen to be too fussy and counter-intuitive compared with conditions "just don't show the user things they can't do", and would have had to be a replacement for conditions as well. I absolutely agree with the "don't have two ways to do it", and I lean towards the more elegant and simple "don't offer the user things they can't do" approach of Conditions. I'd like a way to explain *why* something is not available (like the current "where's my field", a "where's my transition" would be great) but not a pre-validator. Too ugly.
Interesting. I first came up with having the ability for a condition to have an optional "feedback" field such that, if set, it didn't hide the transition, it displayed the transition and provided the feedback when selected; however, I rejected the idea in favor of pre-validators as being more intuitive. I agree that they are basically the same thing, and that augmenting Conditions would be less messy overall. Failing that, a "where's my transition" would be okay as long as people think to use it, but I prefer a less optional approach.