Get started

Use case library

JWT expression editor

JWT expression parser functions

JWT workflow functions

JWT remote actions

JWT automation rules

JWT calculated fields

JWT calendars

JWT properties

JWT JQL functions

Cloud migration hub

Additional product info

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

Compare with Current View Page History

« Previous Version 56 Next »

One of the most important features of JWT is the easy accessibility to Jira data stored in system fields, custom fields and a significant number of other virtual fields that are made available by the JWT implementation.

You can access, validate, do mathematical calculations and manipulate the values found in these fields through the use of field codes .  

A field code is a unique identifier (key) that can be used in any parser expression. At the same time a field code is a safety feature that makes your expressions immune to custom field renaming.


Check out the following pages to familiarize yourself with field codes.


 Field code notation

Depending on the context in which they are being used, field codes will contain a prefix following this notation :  {origin.field} .

What is a context?

A context basically determines where JWT will pull data from. Available  contexts  (or  origins ) in JWT are:

ContextDescriptionExample
issue

The issue that currently being processed by a workflow function or automation rule.

The most commonly used context in JWT.

%{issue.description} 

The description of the current issue.

parent

The parent of the issue that is processed by a workflow post function or an automation rule.

(warning) Only valid for sub-tasks.

%{parent.summary}

The summary of the parent issue.

seed.issue

The  issue currently being processed by a workflow function that is capable of analyzing multiple issues (e.g. subtasks()).

These issues are called seed issues.

Alternatively you can add ^ as a prefix.

%{seed.issue.summary}

The summary of a seed issue.




issue.project

system Some data does not have an issue context (e.g. the currently logged in user or the system date and time).

%{system.currentUser}

The current user (e.g. executing the post function).




Additional contexts for automation rules

These additional contexts are available for automation rules:

ContextDescriptionExample
trigger The issue, user, version, component or project event that triggers the execution of the rule.

%{trigger.issue. description}

The description of the issue triggering the automation rule.

selector The  issue currently being processed by a selector  (e.g. an issue returned by a JQL query).

%{selector.issue.cf10021}

The value of the custom field with the ID 10021 from the issue currently being processed by a selector.

The  prefix  is a referential part of the field code and  will be inserted into the expression  whenever you select a field from a dropdown list (as shown below).   

INSERT SCREENCAST

The additional contexts can be used in combination with the standard contexts (e.g. parent, seed).

Example: %{trigger.parent.summary}

Field codes in the documentation

Wherever field codes are used in the documentation, they will be notated with three periods (...)  instead of a prefix. 

  • %{...summary} 

  • %{...cf10021}

  •   {...duedate}

Field codes for Jira standard or system fields will display the attribute in a legible form like  %{issue.summary} .

All selected custom field will be notated like  %{.issue.cfnnnnn} where nnnnn contains the Jira custom field ID.

Once an expression has been saved, the real name will be displayed in the configuration element.

The purpose of using the cfnnnnn notation is quite simple -  custom fields can be renamed .

Numbers vs. text (strings)

Field codes must always be enclosed by curly brackets {} but if they are used for text-strings, the brackets must be preceded by a percent sign % . 

  • Number fields can be referenced as numbers using the following notation: {issue. somenumberfield }. ((info) no preceding % sign)
    • If a field is not set or does not return a number (e.g. a text field ), it is evaluated to null .
  • String fields : Any field type or data type is susceptible of being transformed to text, so any field can be referenced as a text-string value using the following notation: %{issue.somefield}.
    • If a field has no value ( null) , an empty string will be returned.
  • Cascading Select fields are treated as text fields, where i is the index that represents the level to be accessed. ( i = 0 is used for base level) are notated as %{issue.somefield.i}

A complete list of all available data types can be found here.


Readable fields

The list below contains all fields that can be read by JWT.