Control editability of one field depending on the value of another field

Jens Toft

Hi all,

In most systems that I know of this question would be the easiest to answer, but in Jira it seems impossible.

I have made a custom field on jira issues that is updated when worklog activity has been processed in our Accounting system. The field "ERP Entries Exist" is a radio button.

Now I want to make sure that issues cannot change parent link if "ERP Entries Exist" = Yes, but I keep hitting roadblock.

I use Jira Cloud on a standard plan, and I have Script Runner.

The Parent Link is not part of a Page but edited directly in the issue detail box.

1st attempt:

Scriptrunner Behaviour: Thow an error when 1field is changed if field 2 = yes.

Problem: Error not allowed on behaiours

2nd attempt:

Scriptrunner Behaviour: Set field 1 to readonly if field 2 = yes.

Problem: Readonly only works on fields on screens, not on data level i.e. field in the detail box.

3rd attempt

Listener: Revert field 1 to old value if field 2 = yes

Problem: Listener doesn't know the old value to revert to.

4th attempt:

Handle with a Jira Automation: Not an option due to the very limited number of automation runs with a standard plan.

I come fom an ERP consuling world (Microsoft Business ntral) where a request like the above would be categoized as a very simple task and estimated to 2minuttes of development/configuration. Maybe I just haven't found the rigt apprach in Jira yet, but t seems like Jira is not prepared for adding logic that ensures dataintegity.

I've had two different Jira Consultants involved. One never came back, the other said it was not possible, but I can't believe that is true.

Any advice is welcome, also to other forums if this one is not the place to ask this question.

Mihai_LeanZero

Hi @Jens Toft,

Automation is probably cheaper than you think, and it can do the same revert without code. Jira Cloud has no native field lock (https://support.atlassian.com/jira/kb/how-to-restrict-field-editing-to-specific-users-in-jira-cloud/), so a revert is the realistic route.

I tested this today on a test site. A label stood in for your field.
1. Trigger: Field value changed, Fields to monitor = Parent, For = Edit work item.
2. Condition: JQL "ERP Entries Exist" = Yes.
3. Action: Edit work item, no fields set, with this under More options: {"fields":{"parent":{"id":"{{fieldChange.from}}"}}}

The old parent came back within about 3 seconds. Without the label, the rule left it alone. {{fieldChange.from}} is the previous raw value (https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/), so this only restores a parent the item already had.

Billing is per step: "Every trigger, condition, action, branch, and loop that runs in a flow counts as a step toward your usage." Standard gives 400 steps per user per month, pooled (https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/). The trigger also fires once when an item is created with a parent (https://jira.atlassian.com/browse/AUTO-2052). By my arithmetic that's trigger plus condition per parent change, and the edit plus a comment on top when it reverts.

Like Artyom said, the user gets no error and only sees the old parent come back, so add a comment action that says why. You can vote on JRACLOUD-69298 for real field security (https://jira.atlassian.com/browse/JRACLOUD-69298). I haven't tested board "Change parent" or bulk edit with this rule.