Transition related issues (Deprecated)

Owned by Daniel Barrow
Aug 24, 2023
6 min read

This post-function has been deprecated and replaced by Transition Issue(s). It could be removed at any time. You can still use it, but it is highly recommended that you update any workflows that use this post-function.

A workflow post-function that triggers a transition on all issues related to the current issue

When you add this post-function to a transition and trigger it, the add-on will trigger the first transition encountered, applicable to the related issue(s) and specified workflow, if any.

You might want to specify multiple transitions if the related issues can be in different statuses and/or use different workflows.

  • This post-function does not work with remote links (links to Jira issues residing on another Jira instance/server).

  • JMWE now considers "symmetrical" link types (such as "relates to") as one link direction instead of two on the configuration screens and in the post-function execution.

To add the 'Transition related issues' post-function to a transition:

  1. Click Edit for the workflow that has the transition you wish to configure the post-function on.

  2. In the Workflow Designer, select the transition.

  3. Click on Post Functions in the properties panel.

  4. Click on Add post function.

  5. Select Transition related issues from the list of post-functions.

  6. Click on Add to add the post-function on the transition.

  7. Specify transition(s) either in the table or as a result of the calculated transitions Groovy script. See below for more information.

  8. Select the issues to operate on from the Which issues(s) drop-down.

  9. Click on Add to add the post-function to the transition.

Transition(s)

Trigger one of the following transitions

Input the transition name(s) or id(s) and optionally the workflow name manually or using the Transition picker. If you do not specify the workflow name (manually) the app 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.

To pick a transition using the Transition picker:

  • Click on Transition picker

  • Choose a workflow from Workflow name

  • Select a transition from the list of transitions displayed

  • Select the checkbox "Workflow Name",  to target a transition in a specific workflow. Leave it unchecked to trigger the transition of any workflow.

  • Finally, click on either

    • Use Transition Name - recommended if you want the post-function to search for the transition to trigger by name, which is useful when targeting multiple workflows.

    • Use Transition ID - if you want to differentiate between transitions that bear the same name.

  • Click on Add.

To remove a transition: Click on the Remove link for the specific transition

To reorder transitions: Select and move the transition in the table to reorder the list

Trigger a calculated transition

Input a Groovy script that returns transition name(s) or id(s) and optionally the workflow name. To specify the 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 specify multiple transitions, write a Groovy script that returns a collection of transition names or IDs. Eg: ["Done","44@@Employee workflow"]

Which issue(s)

Select the issues to operate on. They can be:

  • Linked issues: Select issue(s) linked to the current issue through any link type or a specific link type such as blocks, is cloned by, etc.

  • Sub-tasks of the current issue: Select this option to operate on the sub-tasks of the current issue

  • Parent issue of the current sub-task: Select this option to operate on the parent of the current issue

  • Issues that belong to the current Epic: Select this option to operate on the issues that belong to the current Epic

  • Epic of the current issue: Select this option to operate on the Epic of the current issue

  • Child issues of the current issue in the Portfolio hierarchy: Select this option to operate on the child issues of the current issue in the Portfolio hierarchy

  • Parent issue of the current issue in the Portfolio hierarchy: Select this option to operate on the parent issue of the current issue in the Portfolio hierarchy

  • Issues returned by a Groovy script:  Input a Groovy script that returns either a single Issue object, or a Collection of Issue objects, or a String representing the key of an issue, or a Collection of Strings each representing an issue key. For example:

    • "TEST-1"

    • ["TEST-1","TEST-2"]

    • ComponentAccessor.issueManager.getIssueObject("TEST-1")

    • [ComponentAccessor.issueManager.getIssueObject("TEST-1"),ComponentAccessor.issueManager.getIssueObject("TEST-2")]

    • issue.parentObject

    • issue.getLinkedIssues()

  • Issues returned by a JQL search:  Input a JQL search expression, including an optional Groovy Template markup. For example:

    • project = TEST returns issues of the project with the key TEST

    • project = ${issue.get("project").key} and assignee = ${currentUser.name} returns issues of the project the current issue belongs to and assigned to the current user.

    • To operate on issues of a project with key TEST and issue type name same as the value in a text field

      <% if (issue.get("Single line text")) { %> project = TEST and issuetype = ${issue.get("Single line text")} <% } else { %> issuekey=INVALID-1 <% } %>

       

  • Note that the <% if %> block is necessary to avoid an invalid JQL query when the Single-line text field is empty. In that case, the template will return a valid JQL query that returns no issue (issuekey=INVALID-1). This is in general applicable to JQL operating on select type fields with pre-determined values like Affects Version/s, Checkboxes etc.

  • The maximum number of issues returned by a valid JQL is limited to 1000.

Options

  • Skip workflow conditions: Ignores the workflow conditions on the triggered transition, if any.

  • Skip workflow validators: Ignores the workflow validators on the triggered transition, if any.

  • Skip permission check: Skips the check whether the current or the "run as" user (explained below) has the appropriate permissions to trigger the transition.

  • Trigger a Manual Transition Event on transitioned issues: Trigger a WorkflowManualTransitionExecutionEvent for each issue that is transitioned. This event might be required by other apps.

Transition screen

If the triggered transition on the related issue(s) uses a transition screen you might want/need to provide a value for fields(such as Resolution) present on the screen. Look below to know how to add/set/remove fields.

  • To add a field: Select a field from the list of fields and click on Add.

  • To Remove an added field: Click on Remove to remove a field.

  • To Set a field value: 

    • Copy value from current issue: Copies the field value(s) from the current issue.

    • Set field value to constant or Groovy template: You can set the field to a constant value that can optionally include the result of a Groovy template. For example: 

      • To set the Fix Version/s to 2.0, you can specify 2.0 in the value box. 

      • To set the Description of the issue, you can specify This bug has been raised by <%=issue.get("reporter").getName()%> with <%=issue.get("priority").getName()%> priority. Act accordingly. in the value box.

    • Set field value from Groovy Expression: You can set the field to the result of a Groovy expression. For example: To set the Assignee to the Reporter of the issue, you can specify issue.get("reporter") in the value box.

See the Expected Value tab of the Groovy help editor or refer to the documentation to know more about the expected value of the selected field.

Note that you can also 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 text of the comment can either be a

    • Text or Groovy template: A fixed text that can include a Groovy template markup that can be used as the comment body. 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, which can either be a fixed text or the result of a Groovy expression or the result of a Groovy template.

  • Comment visibility

    • 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. For no restriction, leave the field blank.

    • 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. For no restriction, leave the field blank.

Run as

Run as user: Select one of the following options to set the author of the action performed by this post-function as:

  • Current user: The user transitioning the issue.

  • Specific user: The user specified in the select-list provided. Start typing into the field to select a user from the list of auto-suggestions.

  • User in field: The user specified in a user picker field of the issue being transitioned. Select one of the user fields from the list of available options in the field provided.

  • User from script: The user returned by the Groovy script specified in Script. This script should return either the Username of the user or an ApplicationUser object.

    Examples:

    • "jdoe" - Username

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

Conditional execution

Input a Groovy expression that returns true if the post-function should run. For more information see Conditional execution using Groovy expression. Note that the condition will be evaluated once per applicable related issue, with each related issue being available, in turn, in the relatedIssue and deprecated linkedIssue variables.

Error Handling

By default, all errors (Java Exceptions) raised by this post-function, including those raised by custom Groovy scripts, will be logged in the JIRA log file but will not be reported to the user and will not prevent the transition from completing. 

However, when designing new workflows or troubleshooting them, it is more convenient to be notified immediately of any such error during the execution of the transition. On development and staging Jira instances, you can activate error reporting for all JMWE post-functions on the JMWE configuration page, and it is recommended to do so. But on production Jira instances, you might want to show errors only for the post-function(s) being worked on, 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.

Â