Condition on sub-tasks and Validation on sub-tasks are two forms of a same feature for setting restrictions in workflow transitions in relation with current issue's subtasks.
Restriction on subtasks apply to the following characteristics of subtasks:
In this example we show the configuration of a validation for requiring that all current issue's "QA Sub-task" subtasks are in "Resolved", "Closed" or "Done" status, and with resolution set to "Fixed". It also requires that field "Components" in "QA Sub-task" is among parent's selected components.
The validation set in this example doesn't apply any restriction to subtasks different from "QA Sub-task".
Once configured, the validation looks like this:
This parameter filters by issue type the subtasks that will be affected by the restriction (condition or validation).
For selecting all the issue types, don't check any issue type, but check parameter "Allow unselected issue types".
This parameter filters by status the subtasks that will be affected by the restriction (condition or validation).
For selecting all the statuses, don't check any status, but check parameter "Allow unselected statuses".
This parameter filters by resolution the subtasks that will be affected by the restriction (condition or validation).
For selecting all the resolutions (including resolution not set), don't check any resolution, but check parameter "Allow unselected resolutions".
This parameter filters by field value (custom field or system field) the subtasks that will be affected by the restriction (condition or validation).
Leaving this parameter empty doesn't set any filter by field value.
This parameter sets a restriction in form of boolean expression (logical predicate) that should satisfied by subtasks.
Field codes with formats %{nnnnn} and {nnnnn} represent field values in current issue. For representing field values in subtasks field codes should be preceded by ^
prefix, i.e., ^%{nnnnn} and ^{nnnnn}.
Examples:
{00012} <= ^{00012}
requires that sub-tasks have "Due date" equal or later than current issue's "Due date".%{00074} ~ ^%{00074} AND ^%{00017} in ["Blocker", "Critical"]
requires that sub-tasks have "Fixed versions" contained in current issue's "Fixed versions" and Priority is equal to Blocker or Critical.Is the minimum number of sub-tasks requiered to satisfy selected filtering conditions (issue type, status, resolution and field values).
Is the maximum number of sub-tasks allowed to satisfy selected filtering conditions (issue type, status, resolution and field values).
Sub-tasks in unselected issue types will be ignored, i.e., they will not be applied any restriction.
If none of the issue types are selected, checking this option will make the condition behave as if you had selected all issue types.
Sub-tasks in unselected statuses will be ignored, i.e., they will not be applied any restriction.
If none of the statuses are selected, checking this option will make the condition behave as if you had selected all statuses.
Sub-tasks in unselected resolutions (including resolution not set) will be ignored, i.e., they will not be applied any restriction.
If none of the resolutions are selected, checking this option will make the condition behave as if you had selected all resolutions (including resolution not set).
Sub-tasks not satisfying filter by field values will be ignored, i.e., they will not be applied any restriction by number of subtasks.
This parameter is only available in the validator form of this feature. It's a custom message to explain the user the cause that is preventing him/her from executing the transition.
Translations to every language installed in the JIRA instance can be optionally entered.
When using Condition on sub-tasks the transition is simply hidden whenever condition isn't satisfied, so this parameter is not present.