When you add this post-function to a transition and trigger it, the add-on will trigger the first transition encountered, applicable to the current issue and specified workflow, if any.
The only reason you might want to specify more than one transition is if the post-function is added to a "global auto-transition", which can lead to any status. In that case, a different transition can be triggered depending on the current status of the issue.
Configure the post-function
Follow the steps above to add a post-function to a Transition.
From the list of post-functions, select Transition issue(s).
The Transition Issue(s) page will open (Figure 1, right). Configure the post-function as needed, setting the options for the transition, target issue, and other options as necessary. See below for details on each of the configurations.
Note that you need to publish the workflow for the new post-function to take effect.
This section determines which transition will be triggered when the post-function executes. If you select Trigger one of the following transitions, the post-function will select the first applicable transition from the ordered list of transitions.
When selecting transitions to add, you can use the Transition Picker to search for a specific transition and workflow. See Transition picker, below, for more details.
Transition(s) - Select whether to trigger one of the transitions listed, or to trigger a specific transition calculated using a Groovy script.
Transition name or ID - Input a transition name or id.
[Optional] Workflow name - You can optionally add a workflow name. If you do not specify the workflow name manually the post-function will not check for a specific workflow. The app triggers the first transition specified in the table that is applicable to the issue in context, regardless of workflow.
Calculated transition(s) - Enter a Groovy script that returns a transition name or an array of transition names. Input a Groovy script that returns transition name(s) or id(s) and optionally the workflow name. To specify a workflow name, write a Groovy script that returns the transition name or ID along with the workflow name separated by @@. Eg: "Done@@HR workflow". To return multiple transitions, write a Groovy script that returns a collection of transition names or IDs. Eg: ["Done","44@@Employee workflow"]
When working with a list of transitions, a few actions are available:
To remove a transition - Click on the Remove link to the right of that transition.
To reorder transitions - Select and move the transition using the handle ( ) in the table to reorder it.
Figure 2 - Transition picker
The Transition picker (Figure 2, right) enables you to select a specific transition within a specific workflow add that transition to the list without needing to know its exact name or ID. To add a transition using the picker, follow these steps:
Click the Transition picker button.
Choose a workflow from the Workflow pulldown menu.
Select a transition from the Transition pulldown menu.
Select an option on how to reference the transition within the post-function:
Use Transition Name - Click this button to reference the transition by name. This is recommended if you want to use the post-function to target multiple workflows.
Use Transition ID - Click this button to reference the transition by its unique ID. This is recommended if you want to differentiate between transitions that bear the same name.
(Optional) To add the Workflow name in addition to the transition, check the Workflow name checkbox.
The following options are available:
Skip workflow conditions - Ignore all workflow conditions when transitioning the issue.
Skip workflow validators - Ignore all workflow validators when transitioning the issue.
Skip permission check - When executing the transition, do not verify that the “run as” user has the correct permissions to transition the issue.
Trigger a Manual Transition Event on transitioned issues - <what is this option?>
If the triggered transition uses a transition screen you might want (or even need) to provide values for certain fields present on the screen (such as Resolution). When you add a field to the list of fields to populate, each field will have a configuration option for what value to use.
Add field - Select a field from the list of fields and click on Add. The fields added will be listed above the Add field option. For each field added, configure what value to use:
Copy value from current issue - Copy the value from the matching field of the current issue.
Set field value to constant or Groovy template - Enter a static value or a Groovy template that returns the value to be entered.
Set field value to Groovy expression - Enter a Groovy expression that returns the value to be entered.
Remove - Click Remove to the right of any field to remove it from the list.
Please note that you cannot set fields that do not appear on the transition screen.
Likewise, you might also want to provide a comment during that transition:
Comment type -The comment can be a text value or a value generated by a Groovy template or a Grovvy expression.
Text or Groovy template - A static text value that can include Groovy template markup. For example, The issue will be resolved on or before <%= issue.duedate%> by <%issue.assignee%>.
Groovy Expression - A Groovy expression whose return value (of type String) will be used as the comment body. For example, issue.get("description") will add the description of the issue to the issue as a comment.
Comment text -Text that will be used as the comment body; enter a static value, a Groovy template, or a Groovy expression.
Comment visibility - Select a group or a project role to which the comment will be visible. For no restriction, leave the field blank.
Restrict to Group: Restricts the visibility of the comment to a specified group. When you select a valid group name in the Restrict to Group field, the comment will be visible only to the members of the specified group.
Restrict to Project Role: Restricts the visibility of the comment to a selected project role. When you select a project role from the drop-down Restrict to Project Role field, the comment will be visible only to the members of the selected project role.
It is possible to configure the post-function to execute (or not execute) only in specific circumstances. The Condition execution option sets this behavior.