Purpose

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 sub-tasks.

Restriction on sub-tasks apply to the following characteristics of subtasks:

• Issue type of subtasks
• Status of subtasks
• Resolution of subtasks
• Number of subtasks
• Value of subtask's fields

Example: QA Sub-tasks must be in "Resolved", "Closed" or "Done" status, with "Fixed" resolution, and consistent field "Components".

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:

Configuration Parameters

Sub-task's issue types

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

Sub-task's statuses

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

Sub-task's resolutions

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

Filtering by field values

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.

Minimum required number of subtasks

Is the minimum number of sub-tasks requiered to satisfy selected filtering conditions (issue type, status, resolution and field values).

Maximum allowed number of subtasks

Is the maximum number of sub-tasks allowed to satisfy selected filtering conditions (issue type, status, resolution and field values).

Allow unselected issue types

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.

Allow unselected statuses

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.

Allow unselected resolutions

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

Allow unsatisfied condition on field values

Sub-tasks not satisfying filter by field values will be ignored, i.e., they will not be applied any restriction by number of subtasks.

Message to show when validation fails

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.