Skip to end of banner
Go to start of banner

Transition Issue(s)

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

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.

To add a post-function:

  1. Log into your Jira Server instance as an Administrator.

  2. Click on the Administration icon ⚙️ in the upper right corner.

  3. Select Issues.

  4. In the left-hand panel, click Workflows.

  5. Click Edit for the workflow to be edited.

  6. Edit the Transition:

    1. When viewing the Workflow in Diagram view, select the Transition and click the Post Functions link. Click Add post function at the top of the list of existing post functions.

    2. When viewing the Workflow in Text view, click the name of the Transition then select the Post Functions tab. Click Add post function at the top of the list of existing post functions.

Configure the post-function

  1. Follow the steps above to add a post-function to a Transition.

  2. From the list of post-functions, select Transition issue(s).

  3. Click Add.

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

  5. Click Add.

Note that you need to publish the workflow for the new post-function to take effect.

Transition(s)

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 ( (blue star) ) in the table to reorder it.

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:

  1. Click the Transition picker button.

  2. Choose a workflow from the Workflow pulldown menu.

  3. Select a transition from the Transition pulldown menu.

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

  5. (Optional) To add the Workflow name in addition to the transition, check the Workflow name checkbox.

Target issues

The Target Issues configuration set which issue will be updated by the post-function.

  • Which issue(s) - Select the issue type.

    • Current Issue - The issue that is being transitioned and triggering the post-function.

    • Issue/Subtask

      • Sub-tasks of the current issue - Updates will be made to all sub-tasks of the current issue.

      • Parent issue of the current sub-task - Updates will be made only to the parent of the current issue (if any).

    • Epic/Story

      • Issues that belong to the current Epic - Updates will be made to all issues that belong to the current Epic.

      • Epic of the current issue - Updates will be made only to the Epic of the current issue (if any).

    • Portfolio Parent/Child

      • Child issues of the current issue in the Portfolio hierarchy - All child issues will be updated.

      • Parent issue of the current issue in the Portfolio hierarchy - Only the parent issue will be updated.

    • Issue links

      • Issues linked to the current issue through any link type

      • Issues linked to the current issue through the following link type

    • JQL / Groovy

      • Issues returned by the following Groovy script

      • Issues returned by the following JQL search

  • Issue Link - Only available when Which issue(s), above, is set to Issues linked to the current issue through the following link type. Select the required link type between the current issue and the issue to be updated.

  • Groovy script - Only available when Which issue(s), above, is set to Issues returned by the following Groovy script. Enter a Groovy script that returns the ID values for the issue or issues to be updated. See Customizing further with Groovy scripts for more information on Groovy scripting.

  • JQL expression - Only available when Which issue(s), above, is set to Issues returned by the following JQL search. Enter a JQL expression that returns the ID values for the issue or issues to be updated. See Using JQL in JMWE for more information on JQL.

Options

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?>

Transition screen

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.

Run as

Select which user account will be used when running the post-function.

  • Run as user

    • Current user - The user who triggered the transition.

    • Specific user - Select a specific user account to execute the post-function.

    • User in field - Select a User Picker field or other custom field containing user values.

    • User from script - Enter a Groovy script that returns a user ID.
      Examples:

      • "jdoe" - To use a static value username.

      • issue.get("assignee") - To return the current issue's Assignee.

Note: Prior to JMWE 8.4.0, this configuration stores a username value. If an Administrator changes a user’s username, the post-function will fail.

Existing post-functions created before version 8.4.0 should be updated; open the post-function for editing and save it (no changes are necessary). This will update the configuration to use the immutable user ID value.

New post-functions do not need to be updated.

Conditional execution

It is possible to configure the post-function to execute (or not execute) only in specific circumstances. The Condition execution option sets this behavior.

  • Only if condition is true - Check this option to execute the post-function based on the result of a Groovy expression. See Conditional execution/validation using a Groovy expression for more information.

    • Condition - Enter a Groovy expression that evaluates to true or false (or truthiness/falseness).

Error Handling

  • Make transition fail when an error occurs in this post-function - Select this option to make the transition fail when an error occurs while running the post-function. An error message is displayed to the user showing the transition failure.

By default Error handling is turned off. When it is turned off, all errors (Java Exceptions) raised by this post-function, including those raised by custom Groovy scripts, will be logged in the JIRA log file. However, they will not be reported to the user and will not prevent the transition from completing. 

When designing new workflows or troubleshooting them, it may more convenient to be notified immediately of any such error during the execution of the transition. For example, on production Jira instances you might want to show errors only for the post-function(s) being created or updated, in order to avoid disrupting other workflows. To make errors raised by the current post-function prevent the transition from completing and show the error in the browser, select Make transition fail when an error occurs in this post-function.

When the Error handling option is selected on a specific extension, it overrides the configuration on the JMWE configuration page.

If you want to show all errors - to either All Administrators or All Users - configure the option globally on the JMWE configuration page. For example, on development and staging instances, you can activate error reporting for all JMWE post-functions so as to display all the errors (it is recommended to do so); on production instances you may want to activate error reporting only for administrators so that they can be made aware of configuration errors.

You are viewing the documentation for Jira Data Center/Server.

On This Page

  • No labels