Post-function "Transition issues" is used for ordering the execution of a transition in one or more issues. This feature is an alternative to virtual fields "Issue status", "Issue status (delayed writing)", "Execute transition" and "Execute transition (delayed execution)" which is the classic method for executing transitions in Jira Workflow Toolbox.
Post-function "Transition issues" uses the same transition manager as virtual fields above, but with the difference that instead of using the names of statuses or transitions, it uses their internal ID. This has the advantage that the renaming of transitions or statuses will not break your workflow, besides it's more intuitive than virtual field in most cases.
Anyway, virtual fields "Issue status", "Issue status (delayed writing)", "Execute transition" and "Execute transition (delayed execution)" keep working as always, and will keep being irreplaceable for some uses like automatic transitioning of issues newly created by post-function Create issues and sub-tasks.
Available since Jira Workflow Toolbox 2.3.0.
Select the transition issue post-function. The following screen shows the configuration page.
Once configured, the transition will look like this:
There are 9 different modes for selecting the issues whose field values are going to be set: Current issue, Parent Issue, Linked Epic, Linked Issues, Subtasks, Sibling Subtasks, Issues under Epic, Sibling issues under Epic, JQL query and Issue List expression.
If the current issue should be transitioned, a delay will be forced if nothing is specified in the Transition Options. The function must be placed before the Fire Event post function.
The parent issue of the current issue. If the current issue is not a subtask, nothing will happen.
Epic linked to current issue. If the current issue has no linked epic, nothing will happen.
Issues linked to current issue. If current issue has no linked issues, nothing will happen.
Subtasks of current issue. If current issue has no subtasks, nothing will happen
Issues under same epic as the transitioned issue. If the current issue has no linked epic, nothing will happen.
In this issue selection mode we use JQL, which is a language provided by Jira for doing advanced issue searching.
You can insert field codes with format %{nnnnn} in your JQL query. These field codes will be replaced with the values of the corresponding fields in current issue at execution time, and the resulting JQL query will be processed by Jira JQL Parser. This way you can write dynamic JQL queries that depend on values of fields of current issue. Example: issuetype = "%{00014}" AND project = "%{00018}"
will return issues in same project and with same issue type as current issue.
When you write your JQL for selecting the issues, take into account the following advices:
summary ~ "%{00021}"
will return issues with current user's full name. As full name can contain spaces, we have written the field code between double quotes.issuekey in ("%{00061}")
will be rendered in runtime like issuekey in ("CRM-1, HR-2, HR-3"), which is syntactically incorrect. On the other hand, JQL Query issuekey in (%{00061})
will be rendered in runtime like issuekey in (CRM-1, HR-2, HR-3), which is correct.When we enter our JQL query, a syntax pre-checking is carried out in order to verify that it's correctly written. But when we insert field codes in our JQL query, the definitive form of the query that will be executed is unknown, since it depends on the actual values of the fields in runtime. In these cases the syntax pre-checking is done with speculative values given to the fields, and it might happen that fake syntax errors are reported. In order to inhibit the JQL syntax pre-checking you should enter //
at the beginning of the line. Those characters will be removed in the actual JQL query that will be executed.
Example:
In this issue selection mode we use an issue list expression according to the syntax of the Expression Parser. Here you can find Examples of Issue List expressions.