Summary

In Jira there isn't an out-of-the-box way of preventing specific field changes in Jira, but through Automation Rules we can implement a mechanism that reverts the change right after it happens.

Jira Cloud has a similar implementation documented on How to revert a Custom Field value when edited by unauthorised users using automation.

This is a workaround while the Feature Request below isn't addressed:

JRASERVER-15297 - Getting issue details... STATUS

Environment

Any version of Jira Software or Jira Service Management Data Center or Server.

Automation for Jira may need to be installed if not bundled already.

Solution

The solution is to monitor for the specific field changes and, if the change matched the desired criteria, revert it

Caveats

• Toggling "execute this rule immediately" may allow for reverting the change before the user sees the new values they inputted, but may slow down response times for operations
• There isn't a way to immediately notify the user of the reverting changes — though e-mails and comments can be added to the issues

Example case

The following screenshots and snippets address the following: If the Epic Link field is cleared, revert it to the previous value (the term Epic was renamed to Feature in this example, too).

Step 1) Configure the Trigger to "Field value changed"

Checking the "Execute this rule immediately" causes the user to have the impression the new value they inputted wasn't even accepted, but the history record in the Issue reveals it was (for a very brief moment).

Step 2) Configure the conditions

In this case, we want to revert the Epic Link so it's a "Related issue condition". To revert changes to the Issue's fields, choose "Issue fields condition":

Other conditions can be added to revert changes if the "user who triggered the event" (i.e. edited the Issue) isn't part of some Role or Group:

Step 3) Set the "Edit Issue" Action

On the "Edit Issue" Action, select the fields you want to revert and type in the Smart Value expression:

{{fieldChange.fromString}}

in the dropdown:

• {{fieldChange.toString}} contains the new value the user inputted to the field.
• {{fieldChange.fromString}} contains the previous value of the field.

What the Automation Rule's doing in this example is intercepting the field edition and re-applying the previous value (if the conditions pass).

Step 4) Setup additional notification Actions

While this may accomplish the requirement of reverting "invalid changes" to fields, the users who have their input reverted may not be aware of what's happening (and even think something's wrong in Jira).

The current ways of notifying the user through an Automation Rule are:

• Add a comment to the Issue informing of the revert change and "@ mention" the user
• Send an e-mail to the user informing of the revert change (may not be as immediate)
• Notify channels or rooms through app integrations (like Slack, Teams, etc)

The user who triggered the automation in this case is stored in the {{initiator}} Smart Value (refer to Jira smart values - users for more on this).

For example, to log the action in the audit log, we can use this snippet:

User {{initiator.displayName}} tried to change the Epic/Feature Link from "{{fieldChange.fromString}}" to "{{fieldChange.toString}}" and was reverted.

And for the comment, this, that works as a mention to the user:

Hi [~{{initiator}}].
The Epic/Feature Link can't be empty and you change was automatically reverted.
Please input a valid Epic/Feature.
_(this is an automated comment)_

There is a feature request to allow an on-screen feedback:

JIRAAUTOSERVER-581 - Getting issue details... STATUS

Example case result

Here is how the Automation Rule will look after setting an Epic Link to a valid Issue then clearing the field:

And here, how the Issue history looks:

Notice how the "Feature Link" was changed from JIRA-1 to empty and reverted automatically (last line).