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.
The 'Clear Field Value' post-function clears the value of a specified field, after a transition has been completed.
You must specify the field to be cleared. For example:
For information on how to configure a post-function in JIRA, see the JIRA documentation.
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. It means that 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)
You can find more generic description of precondition here
Clear 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
If you don't specify anything here, the transition on the related will be performed under the same user, who triggered this post function on the origin issue. Thus that user must have the necessary permissions on the related issue.
However, in some restrictive setup that user might not be allowed to do so on the related issue. He might not even see the project of the related issue!
With 'Perform As User' you can specify a different user account which owns the necessary permissions. Usually this user account is assumed to be only technical (impersonation), with broad permissions, but not used to log into Jira by in life persons.
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. For further example go here.
Position of the Post Function
It is important to place the post function in the correct order of other post functions.
The 'Create' transition is the very fist transition, which does not yet has a source status (only destination status - usually Open, but could also be another).
Instead of using the "Clear Field Value" post function in the Create transition, you might consider to just configure no default value for that custom field and don't show it on the create screen.
If you are using the "Clear Field Value" post function in the Create transition, you must put it before the "Creates the issue originally" post function except when clearing labels, which need to be cleared after the issue has been created.
Any other Transition (not Create)
Put the "Clear Field Value" post function anywhere before the "Update change history for an issue and store the issue in the database." post function
A workflow is configured so that the 'Close' transition has the 'Clear Field Value' post-function. The function is configured to clear the 'Security Level' field. If a user closes an issue on this workflow, the value of the 'Security Level' field will be cleared.
Supported Field Types
In its different modules (especially those for workflows), the JSU app supports many different field types. System fields, as well as custom fields.
However you should be aware, that not all field types are supported. Also not in all combinations. We think we cover the most important field types and still are continuously adding and improving which and how different field types are supported. But the one you need, might just not (yet) work. Some custom fields of other third party app might never get supported.
For that reason you should always test anything you do with the JSU app with fields. Before you buy a license for JSU, try it with a free evaluation license, if it works for you.