Can Automation rules edit a hidden field?

Benjamin Peikes

We have created an automation rule that runs on some transitions. It's supposed to edit a field that should normally not be available to users. Initially the automation rule was failing because the field we want to edit is not on the "Edit" screen for the project.

We've added the field to the Edit screen, and put it on a tab we called "Transitions" so that its not a field that is easily editable directly by the user. It's supposed to only be editable via the transition that has it's own screen.

This seems odd, that Automation only has access to fields available on the Edit Screen, but that is what seems to be true. Can someone validate that Jira works this way?

Support Team [Clearvision]

That's interesting as I didn't think that was required either when creating Automations within Jira.

I setup an automation rule to update the 'Approvers' field on Issue Creation despite it not being on any Screens and it worked fine.

However in the documentation regarding advanced editing:

https://support.atlassian.com/jira-software-cloud/docs/advanced-field-editing-json/

---

Why is my field not editable?

If you've retrieved the createmeta or editmeta for your project or issue, the field you're trying to edit may not show up in the resulting JSON. This means when a rule attempts to edit or create the issue, it will fail with an error in the audit log.

This will most likely be due to the field missing on the appropriate edit or create screen in your project. To address this, go to Jira settings > Issues > Screens and ensure the field you’re trying to update is on the appropriate edit or create screen.

Additionally, ensure that the automation rule actor has the right permissions to edit or create issues on your project.

---

 

So I tried again with a custom field in case it was a System field that bypasses it. Again this worked fine. Next instead of using the built in field selector I used the advanced setup with JSON:

---

{
"fields": {
"customfield_10029" : { "value": "1" }

}
}

---

Again this worked fine. I also changed it from on Creation to when transitioned as you mentioned that, however it still worked. 

 

I tried via the API and this time it did get that error:

{"errorMessages":[],"errors":{"customfield_10029":"Field 'customfield_10029' cannot be set. It is not on the appropriate screen, or unknown."}

So it seems that it works within the application, but if using the Rest API the field must be returned in 'createmeta' or 'editmeta' responses or you get that error.