On this page
Use case
Check whether the current issue has any unresolved sub-tasks.
This is particularly important if you want to block a parent issue as long as work is still being done on related sub-tasks.
This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator.
Configuration
Jira expression*
issue.subtasks.filter(s => !(s.resolution != null)).length == 0
This expression makes sure that there are no sub-tasks of the current issue that don't have a resolution set.
Variations
You can easily modify this use case to check for specific resolutions or statuses.
Jira expression*
issue.subtasks.filter(s => !(s.resolution.name == "Done")).length == 0
This expression makes sure that there are all sub-tasks of the current issue that have a resolution set to "Done".
Jira expression*
issue.subtasks.filter(s => !(s.status.name == "Done")).length == 0
All sub-tasks must be in the status of DONE
Jira expression*
issue.parent.subtasks.filter(sub => sub.status.id != 10001).length == 0
This expression checks that all sibling sub-tasks are in status with id 10001.
Sibling sub-tasks are all issues under the current issue's parent issue.
Related examples
Evaluate issue links and hide transitions based on the outcome. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. ADVANCED Make sure that an issue is not in an active sprint. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. BEGINNER Block transitions on weekends or any other day of the week. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. BEGINNER Evaluate a Date Picker field and block the transition if it has not been updated. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. BEGINNER Check whether an epic has all issues under it in a certain status. This is particularly important if you want to block an epic as long as work is still being done on related sub-tasks. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. INTERMEDIATE Check whether the current issue is in a particular status. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. BEGINNER Check whether the current issue has any unresolved sub-tasks. This is particularly important if you want to block a parent issue as long as work is still being done on related sub-tasks. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. INTERMEDIATE Make sure that the current user has uploaded a attachment during a definite period of time. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. BEGINNER Check whether the parent of the current issue is of a certain issue type. This is particularly important if you want to reuse a workflow for multiple sub-task issue types but only want a transition to be available if the sub-task belongs to a certain user story or a bug. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. INTERMEDIATE This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. INTERMEDIATE Evaluate different values of the issue in the Parent Link field of the transitioned issue. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. INTERMEDIATE Evaluate if work has been logged in a sub-task to prevent transitioning the parent issue when no work has been logged. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. BEGINNER Evaluate the comments and hide transitions based on the outcome. This use case is only valid for validators as it involves making changes during a transition. An additional error message can be added. BEGINNER Evaluate if a user has logged more than a certain amount of time in the latest worklog. Use case JWT feature Workflow function Use case description Complexity Block a transition based on issue links 
Block a transition based on sprint information Block a transition based on the day of the week 
Block a transition if a predefined field value has not been changed 
Block a transition if some issues under an epic are not in a certain status 
Check current issue status Check for unresolved sub-tasks Check if an attachment was added recently 
Check parent issue type Check the number of times that a field has changed 
Check the number of times that a field has changed. Evaluate the Parent Link field Evaluate worklogs in sub-tasks Validate an issue only if a comment is written during the transition 
Validate worklogs 
If you still have questions, feel free to refer to our support team.
