Dependant Field

Dependant fields depend on issue-values (like other custom fields for example). They allow you to display additional fields based on a selection or value within a parent field. Dependant fields get updated whenever an issue is being created or changed.

At a glance: The three steps of configuring a dependant field

Select & filter the data source
Prepare the value
Select a target field in which the result will be displayed

Selecting the Data Source

Add and/or select the data source which you want to use.

In the following example, we will use a data source with this JSON result:

CODE

{
  "userlist": [
    {
      "id": 1,
      "name": "Mario Speedwagon",
      "username": "mario"
    },
    {
      "id": 2,
      "name": "Anna Sthesia",
      "username": "anna"
    }
  ]
}

Setting up a Context Filter (Optional)

You can choose a specific segment of your data based on issue values with context filter. This is useful in case you have a single JSON result for all issues. Context filter helps you to select a value of your data set as base for the following dependant field.

Example Use Case: Assume you want to add a dependant field to your issue which will display the real name of a user based on a selected username. We also assume you have a preexisting Jira custom select list field named customfield_10010, where you can select the usernames. Your context filter expression would then look like this:

CODE

$.userlist[?(@.username=='{$.issue.fields.customfield_10010.value}')]

(Your data selection is now dependant on the value of customfield_10010 in each issue)

Available Issue Values and Filter Expressions

Depending on the issue values (or type of your issue field), you’ll need different JSON filter expression to filter the data source:

Issue Key: $.issue.key
Issue Id: $.issue.id
Project Key: $.issue.fields.project.key
Project Name: $.issue.fields.project.name
Custom field - Text: $.issue.fields.customfield_10XXX
Custom field - Select list: $.issue.fields.customfield_10XXX.value
Custom field - External assets platform: $.issue.fields.customfield_10XXX[0].originId
Organizations - Jira Service Management - $.issue.fields.customfield_10XXX[0].name
Assignee Account Id: $.issue.fields.assignee.accountId
Creator User Key: $.issue.fields.creator.key
Creator Display Name: $.issue.fields.creator.displayName

Simulating the Result

The field raw results will simulate real time results of your current configuration.

Troubleshooting: Please make sure you have a value pre-selected in the respective custom field within the Jira issue, to prevent errors while testing the context filter.

You can change the issue which is used in the simulation with the option Issue Context, in case you want to test it with a different issue.

More examples and details about context filters can be found in the dedicated section: Context Filter

Value Type

Value Type defines the type of data, which your dependant field will contain. The field Jira Target Field will give you a list of potential target fields in the dropdown menu.

The following field types are being supported:

Text
TextArea
Number
Url
DateTime
UserPicker (must be the Jira accountID of the user you want to select)
MultiUserPicker (must be the Jira accountID of the user you want to select)
Select List (single choice) (must be the same value as in the dropdown list)
Select List (multiple choice) (values must exist in the dropdown list)
External assets platform (must be in the format appKey/originId)

Back to our example use case from above: If the dependant field is supposed to just output a simple username based on a selected name from your select list, you would choose Text as Value Type.

Select Value

Specify the value(s) of your JSON list which you want to be displayed in your dependant field later on, using the respective JSON path.

As in our use case example, you would choose the following JSON path

CODE

$.name

to have the full name of the user displayed in your dependant field.

You can also individualise your value output.

You can, for example, add custom text around your value:

CODE

prefix__{$.name}__postfix

This will result in prefix__Mario Speedwagon__postfix

Or you can build templates:

CODE

{$.name} ID:{$.id}

This will result in: Mario Speedwagon ID:1

Select a Target Field

Select the custom field for your dependant field. The custom field type has to be compatible with the value type of the previous step.

Valid combinations are:

CODE

Text <-> Text Field | Text Area | Url
TextArea <-> Text Area
Number <-> Number
Url <-> Url | Text Field | Text Area
DateTime <-> DateTime
UserPicker <-> UserPicker
Select List (single choice) <-> Select List
Select List (multiple choice) <-> Select List - multiselect
External assets platform <-> External assets platform

Update Condition

Select the update conditions of your dependant field:

Always after issue creation or update
Once after issue creation
Only if target Jira field is empty
Only after issue update

Always (default)

This option will trigger an update after the creation of an issue and after every issue update.

Once after issue creation

This option will trigger an update only once after creating an issue. The dependant value has to be available while the issue is being created in order to work.

Only if target Jira field is empty

This option will always trigger an update as long as the target field is empty.

Only after issue update

This option triggers an update only after an issue is updated. It is particularly useful in combination with the use of automations.
Configure your automation to initially run upon issue creation. Subsequently, this will trigger the dependent field to update following the completion of the automation.

Clear Values

If activated, the target field will be cleared in case of empty results or a missing dependency.

No Issue Refresh

If activated, this field will not trigger an issue page refresh after a value change. An issue page refresh is useful if the target field is visible on the issue view. Dependent fields update their targets in the background. You can tweak the interval at which the app checks for changes while a user is in the issue view in the Settings > UI Configuration section.

Selection Behaviour

When targeting a multi-select-list or multi-user picker, you can choose between two selection behaviours:

Append Missing Options (default): This behaviour will only append values to the current selection without removing any existing ones.
Replace Entire Selection: This behaviour will replace any existing selection with the new selection generated by the dependent field.

Order

If you have more than one dependent field, you can change the order of your fields with this option. This is particularly useful in a setup with multiple interdependant dependant fields, that successively build up opon each other.

Error Notifications

In the Settings section you can determine if you want to receive error notifications. If activated, you’ll receive an email right after an error happens – but only once a day to prevent spam.