/
JMWE Cloud: Prevent field from being changed via JMWE Event-based Actions

JMWE Cloud: Prevent field from being changed via JMWE Event-based Actions

In some scenarios, a Jira administrator may not want a field to receive further modifications in Jira Cloud. However, the Jira administrator may lack the ability to enforce this due to the following:

  1. Jira workflow Conditions and Validators only trigger when a work item is being transitioned. These do not prevent field changes when editing the issue.

  2. Jira work item properties can be used to make a work item read-only upon issue closure (see here), but the Jira administrator may only want to restrict this behavior to selected fields.

 Instructions

You can use JMWE Event-based actions to roll back any unauthorized changes to a field by updating its values to their previous historical state before the unauthorized change.

Note: the configurations detailed below will assist in preventing unauthorized changes to fields, but cannot guarantee with 100% accuracy that all changes will prevented. For example, consider this scenario:

  • User A, who does not have permission to edit the monitored fields, makes a change to the restricted fields. This change triggers the Event-based action detailed below.

  • User B, who is an administrator and has permission to edit monitored fields, makes a change at nearly the same time. The Event-based action is not triggered.

  • User B commits their changes before the running Event-based action completes. The Event-based action will not be interupted, nor will it know that the changes made by User B are legitimate, and the action will perform the rollback as configured.

Though this scenario may have a remote chance of occurring, it is worth consideration when planning your configurations.

  1. Create an Issue Field Value Changed Event-based action. Add any appropriate configurations to limit the scope of the app in the When and If Scope sections to limit when the Event-based action should execute:

    1. The Issue Field Value Changed event should be configured to watch only the restricted field or fields.

    2. Under the When configurations, check the boxes to enable JMWE post function and actions or other Jira automations to make changes to the restricted field(s), if necessary.

    3. Under the If Scope section, use the Projects and Issue Types selections to limit the rollback to specific work items. Additionally, you can add JQL filters or Nunjucks conditions to further limit when edits are allowed, including limiting changes to specific users or groups.

To limit which users or groups can edit restricted fields, you can use the following Nunjucks in your Event-based action, under the If Scope section (replacing groupNameOrId in the code with a group from your instance):

{{ not currentUser | isInGroup(groupNameOrId) }}

If the user performing the edits is a member of the group listed in the code, the expression will evaluate to false, and the Event-based action will not trigger. Otherwise the Event-based action will trigger and it will try to rollback the changes.

  1. Add a “Set issue fields” post function to the Event-based action. It should be an appropriate Nunjucks script to revert any changes to the field using issue | fieldHistory("field name") | last. For example, with the “Components” field:

    {% set changes = issue | fieldHistory ("components") | last %} {% set componentList = issue.fields.components %} {% set componentString = "" %} {% if changes | field("added") | length > 0 %} {% for item in changes | field("added") %} {% set componentList = componentList | filter({id: item}, true) %} {% endfor %} {% endif %} {% for item in componentList %} {% set componentString = componentString + "id:" + item | field("id") + "," %} {% endfor %} {% for item in changes | field("removed") %} {% set componentString = componentString + "id:" + item + "," %} {% endfor %} {{ componentString | truncate(componentString | length - 1, true, "")}}

 Related articles