Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


UI Text Box
typenote

This function has been renamed with the JWT 3.0 release. 

Find the new documentation at:

Copy field values from linked issues or subtasks


Section


Column
width600px


Panel
borderColor#333f48
bgColor#FFFFFF
titleColor#eeeeee
borderWidth1
titleBGColor#333f48
borderStylesolid
titleOn this page

Table of Contents
maxLevel1



Column




Purpose

This post-function allows reading a field values from linked issues and sub-tasks, and write the value into a field in current issue.



Example: Set "Due Date" with latest value among "Sub-tasks" and "Blocking Issues"





Once configured, post-function will look like this:



Configuration Parameters

Source Value

The value that will be read from linked issues abs subtasks, and stored into a current issue's field. There are 3 types of source values available:

  • Field in JQL selected issues: the value of a field in JQL selected issues.
  • Parsed text (advanced mode): a string expression where we can use values of fields in current issue (syntax %{nnnnn}), and in linked issues and sub-tasks (syntax ^%{nnnnn}). Here we can use all the functions available in the Expression Parser.
  • Math or Date-Time expression: an expression returning a numeric value where we can use values of fields in current issue (syntax {nnnnn}), and in linked issues and sub-tasks (syntax ^{nnnnn}). Here we can use all the functions available in the Expression Parser.

Issues that can be Read

  • Linked Issues: issues linked to current issue.
  • Sub-task: current issue's subtasks.
  • Sibling Sub-tasks: when current issue is a sub-task, its parent's other sub-tasks.

Special Operations depending on Source Field Type

  • Date and Date-Time fields:
    • Lowest Date: earliest date among those read.
    • Highest Date: latest date among those read.
  • Number fields:
    • Sum of Values: sum of all the values read.
    • Lowest Value: minimum value among those read.
    • Highest Value: maximum value among those read.
    • Average Value: arithmetic mean of values read.
  • Priority field:
    • Highest Priority
    • Lowest Priority

Filtering Conditions

Issues to be read can be filtered by:

  • Issue link type: only for linked issues.
  • Issue types: if no issue type is selected, then no filter by issue type is applied.
  • Statuses: if no status is selected, then no filter by status is applied.
  • Project: three possible options are available ("any project", "current project" and "any but current project").
  • Field values: when a boolean expression is entered, only those issues fulfilling the expression are selected. In this expression we use ^ prefix for field values in foreign issues (linked issues, sub-tasks and sibling sub-tasks): ^{nnnnn} and ^%{nnnnn}, while field codes without prefix correspond to current issue's field values.
    Example 1: boolean condition {00012} <= ^{00012} will require that issues have "Due Date" equal or later than current issue's "Due Date".
    Example 2: boolean condition %{00074} ~ ^%{00074} AND ^%{00017} in ["Blocker", "Critical"] will require that issues have "Fix version/s" contained in current issue's "Fix version/s" and that "Priority" has values "Blocker" or "Critical".

Additional Options

  • Don't overwrite target field if it's already set: when checked, this parameter will make the post-function do nothing in case target field is not empty in current issue.
  • Read linked issues and sub-tasks recursively: transitively linked issues and its sub-tasks are also selected provided they fulfill filtering conditions. This recursive operation is performed with no depth limit, but each selected issue is read only once.
  • Read also current issue: current issue is included in issue selection, i.e., current issue's source field is also read.
  • Run as: Jira user post-function is going to be executed as. This parameter can be set to a fixed user (e.g. "john.nash"), or to a user field (e.g. "Reporter", "Assignee", etc). This parameter is important when we have permission or security restrictions that might prevent fields from being read or written.