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