Force the task not to close if sub-task is open

[Sanjeev Parasar]

Is there any way we can force a task on JIRA not to close if the sub-task is not closed?

[GabrielleJ · Accepted solution]

You are looking for a "Condition" script in the "Close" transition of the parent issue to check if all sub-tasks are closed.

Reference: https://confluence.atlassian.com/jira/configuring-sub-tasks-185729507.html#ConfiguringSub-tasks-Blockingissueworkflowsbysub-taskstatus

[Nic Brough -Adaptavist-]

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.

[Jeremy Gaudet]

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"

[Jeremy Gaudet]

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

[Nic Brough -Adaptavist-]

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.

[Jeremy Gaudet]

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.

[Nic Brough -Adaptavist-]

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.

[Jeremy Gaudet]

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.

[Jeremy Gaudet]

For what it's worth, I figured out how to effectively implement a pre-validator and/or feedback condition here:

How do I show validation errors before displaying the linked "resolve" dialog?

[Thomas Rohrer]

Here is what you need - https://confluence.atlassian.com/jirakb/preventing-issues-from-being-closed-while-the-sub-tasks-are-still-open-724928276.html

[Sanjeev Parasar]

Thanks Gabrielle / Nic
The solution suggested worked.