Copy field value to related issues (Deprecated)

Cloud Migration Resources

Planning a Jira Cloud migration? These resources can help you get started:

JMWE Cloud features – Review Cloud features and understand key differences between DC and Cloud.
Migration support from Appfire – Learn how we can help you migrate smoothly.

Copy field value to related issues (Deprecated)

This post-function has been deprecated and replaced by Copy issue fields. 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 copies the value of a field to all related issues (such as linked issues, Stories of an Epic, Epic of a Story, subtasks of an issue, issues returned by a Groovy script or a JQL search, etc.)

When you add this post-function to a transition and trigger the transition, the add-on copies the value(s) of the source field into the destination field value of all the related issues.

  • 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 'Copy field value to 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 Post Functions in the properties panel.

  4. Click Add post function.

  5. Select Copy field value to related issues from the list of post-functions.

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

  7. Select the field from the source field from the Source Field drop-down.

  8. Select the field from the destination field from the Destination Field drop-down. Select "Same as Source field" to copy it to the same field.

  9. Select the issues to operate on from Source issue(s) field

  10. Select the options provided to add required parameters.

  11. Click Add to add the post-function to the transition.

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

Target issue(s)

Select the issues to copy to. 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 

  • Copy only if not set: Copies the value(s) of the selected field into the same field of all the related issues, only when the field is empty on the related issue(s).

  • Ignore empty values: Will not set (clear) the selected field of the related issues, if the value from the current issue is empty or null.

  • Add source value(s) to destination field: Appends the value(s) of the selected field to the destination field of all the related issues. This is applicable only to multi-valued fields.

  • Create missing value(s): Allows automatically creating any missing value(s) while copying values that do not exist in the destination issue's project and hence should be created from the source issue's project. This is applicable only to Affects Version/s, Fix Version/s, Single version and Multi-version picker type custom fields, Components, Radio buttons, Checkboxes, Single select and Multi-select list type custom fields.

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

It is possible to configure the post-function to execute (or not execute) only in specific circumstances. The Condition executional 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 Server / Data Center.

Need support? Create a request with our support team.

Copyright © 2005 - 2026 Appfire | All rights reserved.