This is the documentation of JSU for Jira Server/Data Center. If you are using JSU on Jira Cloud, you can find the documentation here.
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 same issue) or on a related issue, like a sub-task, 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
There are several ways in which preconditions can be evaluated in the context of a post function:
Ignore precondition (By default every precondition is ignored which means that the post function will be always performed)
True (Precondition must be true to execute a post function)
False (Precondition must be false to execute a post function)
Learn more 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 behind 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 same issue) or on a related issue, like a sub-task, 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
With Perform As User, you can specify a different user account that owns the necessary permissions. Usually, this user account is assumed to be only technical (impersonation), with broad permissions, but not used to log into a Jira account as a person. 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 restrictive setups, that user might not have the permissions on the related issue or even might not have 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 other users than the 'Perform As User' user.
Field Value
Please make sure that the value you enter is valid for the datatype of the selected field. Also verify, that the context configuration for the project using this workflow will allow to modify the selected field.
Otherwise, the transition may fail at execution time.
Typically you will use text or numbers as value.
Cascading Select fields
For Cascading Select fields, you may either use the value of the option you would like to set, or it's id. In either case, no need to specify the parent option. For example:
- Vehicles
- Car
- Train
- Bus
- Buildings
- House
- Skyscraper
Using Vehicles as the parameter for Field Value would set the field content to that very option. Same if you would choose Train. Or, assuming 10701 is the ID of House, then the option House will be set.
Special macros
If you use %%CURRENT_USER%%
as the field value (exactly this, nothing more), the user who triggered the post function will be set as value.
If you use%%CURRENT_DATETIME%%
as the field value (exactly this, nothing more), the current date and time will be set as value.
If you use%%ADD_CURRENT_USER%%
as the field value (exactly this, nothing more), the user who triggered the post function will be appended to the existing field content.
Obsolete since 1.4.10: %%ADD_CURRENT_USER%%
Please use the option 'Append value' combined with the macro '%%CURRENT_USER%%' instead.
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 very first transition, which does not yet has 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 to just configure 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 also need to add the "Store Issue" post function after the "Update Any Issue Field".
Note that at step 4 the "Store Issue" post function is needed, which you have to add manually in the workflow configuration.
In our sample we also use a Workflow Precondition before the "Update any Issue Field" post function. This just makes it a more interesting 'real-life' example.
Any other Transition (not Create)
Put 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
Example
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 sub-tasks could be set to the current user (the one changing the status on the parent).
Another example:
A developer has fixed a Bug. He proceeds in the Jira workflow to the status 'Resolved' (this might be triggered from his code pushed to Bitbucket). The 'Update any Issue Field' now adds a label 'testing-required'.
This would be a very light weight solution. 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.
For that reason, you should always test anything you do with the JSU app with fields. You can try it with a free 30-day evaluation license.