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] · Accepted solution]

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.

[Simmo]

See my response below. If the rule is running as Automation for Jira then we set the override screen security flag which allows us to edit fields not on the screen. This is only available to connect app users.

[Andras M]

Thanks, I think it is very important, when you set "value" in JSON and when "id"...

[John Funk]

Hi Bejamin - I suspect you are right.

@Simmo  - Can you verify? 

[Simmo]

Hey folks. 

So, the answer is that it depends on who the rule is running as. If the rule actor is set to our user "Automation for Jira" then it shouldn't need to be on the screen as that user has some extra permissions that allow it to bypass the screen check.

However, if the user has been changed to someone else, then it will need to be on the screen as Jira enforces this at the API level and we can't get around it.

Cheers,

Simeon.