This is the documentation of JSU for Jira Server/Data Center. If you are using JSU on Jira Cloud, see our JSU Cloud documentation.
Description
The Update Any Issue Field post function updates any field to a specified value after a transition has been completed. This can be a system- or a custom field. The field can be on the issue in transition(within the same issue) or on a related issue, like a subtask, a linked issue, or an issue within an Epic (during the transition on the Epic). In addition to setting values to fields, the Update any Issue Field post function can also add comments.
Configuration
You must specify the field and the desired value. For example: 
Precondition
If you are using preconditions with a JSU post function, you can use the following options to define how the precondition is evaluated:
Ignore precondition (default): Every precondition is ignored which means that the post function will always be performed
True: Precondition must be true to execute a post function
False: Precondition must be false to execute a post function
The precondition setting is available on our post function configuration pages, and it is set to ‘Ignore’ by default. You can learn more about our preconditions in Workflow Preconditions.
We use the Update any Issue Field post function like this in the 'Start Progress' transition of our Story issue types. If the Story is part of an Epic, the Epic status will be set to IN PROGRESS.
In the past, users forgot to change the Epic status in time and it was left as TO DO. Using JSU this does no more happen.
Update field on all issues related as
The field can be on the issue in transition(within the same issue) or on a related issue, like a subtask, a linked issue, or an issue within an Epic (during the transition on the Epic).
See Related Issues for more explanation on this topic.
Perform As User
When choosing a user account to run a post function, the account specified must have the appropriate permissions to perform the actions of the post function, for example, creating an issue or adding a comment. You can specify a different user account that owns the necessary permissions that acts only as a technical (impersonation), with broad permissions, but not used to log in to a Jira account as an individual.
If you don't specify a user here, the transition on the related issue is performed as the same user who triggered this post function on the origin issue by default. Therefore that user must have the necessary permissions on the related issue. In some setups, that user might not have the required permissions on the related issue or even access to the project of the related issue.
In combination with the User is in Any Users condition, you can hide a transition from all users other than the 'Perform As User' user.
Field Value
With JSU, you can copy or set field values on issues created through a post function. Typically you will use text or numbers as values.
On this page: |
When setting values to fields, it’s important to ensure the data you define is compatible with the field type. For example you cannot update a Number field with a text-value, "Hello world". Similarly, you cannot update a User Picker field with data that is not a valid user. You should also ensure that any fields you want to update are present on any screen/s related to the context or transition your rule executes from.
If any configuration is not valid, then JSU will be unable to update the desired issue/s as instructed.
Cascading select lists
For cascading select lists, you can either use the value (name or number) of the option you would like to set, or the option ID. When using the value, there is no need to specify the parent option. For example:
Vehicles
Car
Train
Bus
Buildings
House
Skyscraper
Using Vehicles as the parameter for Field Value sets the field content to that option; similarly, if you use Train.
Using the option ID for cascading fields
If the set value you define occurs more than once in the cascading select list, use the option ID instead of a name. The option ID lets JSU determine the correct value to assign in the new issue.
Example:
A custom cascading select list called Onboarding Select contains: Marketing and Onboarding - Marketing.
To use the parent option, Marketing, enter the option ID of the parent option. Here, the option ID for the parent option is 10200.
In the Set configuration field, enter 10200 then select Onboarding Select.
The option ID is not the same as a custom field ID. The custom field ID in this example is the ID assigned to the Onboarding Select custom field. Each option configured for the Onboarding Select cascading field is assigned a unique ID. To find an option ID, see Atlassian’s How to find any custom ID to select your preferred method, and then locate the option ID instead of the custom field ID.
Field reference macros
JSU supports the use of macros to reference data or issue field values when configuring some post functions, for example, Update Any Issue Field, or in the Set and Copy operations for the Create a Linked Issue post function.
Legacy system field references
Support for referencing the Current User, Previous User, and Current Date and Time is provided by using the macro syntax below. You can use only one legacy macro at a time to set or update a field. Legacy macros cannot be combined with the
%%CURRENT_USER%%: The user who triggered the post function will be set as the value.%%PREVIOUS_USER%%: The field is updated with the previous user assigned to the field. This is valid for single-user picker fields in the ‘Update Any Issue Field’ post function.%%CURRENT_DATETIME%%: The current date and time will be set as the value.%%ADD_CURRENT_USER%%: OBSOLETE The user who triggered the post function will be appended to the existing field content.
Obsolete since JSU version 1.4.10: %%ADD_CURRENT_USER%%
Use the option 'Append value' combined with the macro %%CURRENT_USER%% instead.
Extended system and custom issue field references NEW
From version 2.43.0, you can reference any issue field using the prefix issue followed by the field name, for example, %%issue.Assignee%% or %%issue.Labels%%. This syntax can be used in the Update Any Issue Field post function and with the Set and Copy operations for the Create a Linked Issue post function.
Multiple field references
You can provide multiple issue field references using macros, for example, you can update a Description field so that it references %%issue.Approver%% is %%issue.Reporter%% where approver is a custom field. Similarly, you can update a comment field with %%issue.Approver%% update %%issue.Creator%% on change to %%issue.Security Level%%.
If you need a list of Jira system fields for Jira Server/Data Center, see Atlassian’s Issue Fields and Status.
See also
Position of the Post Function
It is important to place the post function in the correct order of other post functions.
Create Transition
The Create transition is the first transition, which does not yet have a source status (only destination status - usually Open, but could also be another). Instead of using the Update any Issue Field post function in the Create transition, you might consider configuring a default value for that field.
If you are using the Update any Issue Field post function in the Create transition, you must put it after the "Creates the issue originally." but before the "Re-index an issue to keep indexes in sync with the database." post function. Depending on the field type, you must add the Store Issue post function after the Update Any Issue Field.
In step 4 the "Store Issue" post function is needed, which you must add manually in the workflow configuration. In our example, we use a Workflow Precondition before the Update any Issue Field post function.
Any other Transition (not Create)
Use the Update any Issue Field post function anywhere before the Update change history for an issue and store the issue in the database post function
Examples
See the above example of a Story changing the Epic Status of its Epic. Or, whenever a parent issue is set to IN PROGRESS, the assignee of all its subtasks could be set to the current user (the one changing the status on the parent).
A developer fixes a bug and proceeds in the Jira workflow to the RESOLVED status (this might be triggered from his code pushed to Bitbucket). The 'Update any Issue Field' now adds the label 'testing-required'.
There are also cases when you need a more complex solution. Have a look at Testing and Fixing Bugs.
For more information on how to configure a post function in Jira, see the Jira documentation.
Supported Field Types
JSU supports many different field types such as system fields and custom fields. However you should be aware, that not all field types are supported, and not in all combinations. We aim to cover the most important field types and are continuously adding and improving how different field types are supported. Some custom fields of other third-party apps might never be supported. You should always test anything you do with issue fields with JSU. You can try it with a free 30-day evaluation license.