Hello Jira Community,
We're facing a challenge with our issue management process across different projects. Historically, this project used three custom fields with pre-filled data to serve as descriptions for three different issue types (stupid, but that's current situation). However, this setup complicates issue transfers between projects because these custom fields do not match the standard "Description" field used elsewhere, resulting in data not being transferred properly.
To streamline our process, we plan to hide these three custom fields to avoid data loss, while setting up an automation to copy their contents into the standard "Description" field. The automation functions correctly when the custom fields are visible but fails to execute when these fields are hidden.
Has anyone encountered a similar issue or does anyone have insights on how we can ensure the automation works even with the fields hidden? Any tips or advice would be greatly appreciated!
Thank you!
Hi @Karolis Pocevicius -- Welcome to the Atlassian Community!
You are correct: when rules use the Edit Issue action, the fields to update must be visible on the view. This is because rule actions use the REST API endpoint with the default parameters for things like edit issue.
That edit issue endpoint has an optional parameter which allows updating hidden fields: overrideScreenSecurity. Unfortunately it requires using an actor with global admin permissions. https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-put
Thus it may be possible to use a rule with such an elevated permission actor to call the REST API endpoint and pass the optional parameter to update the hidden fields. I suggest this is quite risky having a rule actor with such permissions just to edit the field.
Have you considered other approaches to hide the information and not have access / permissions issues, such as using Entity Properties?
Kind regards,
Bill
Welcome to the community.
The problem here is that Automation respects the edit screen for an issue. If your field is not on it, it can't edit it.
But that does not apply to hidden fields.
So, your only option is to add the field to all the screens, and then hide it in all the field configurations.
This should do the trick.
See also AUTO-295
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the welcome and your suggestions.
I've confirmed that the fields are indeed added to all necessary screens (Create, View, Edit) for the issue types involved. I also tried hiding the fields in field configurations as you suggested. When I run the automation, it indicates success, but the field values are not copied unless the fields are set to "Show" in the field configurations. This suggests there might be a dependency on field visibility that affects the automation's ability to copy values.
Is there anything else I might be missing, or is there a known issue with hidden fields in automation that I should be aware of? Any further insights would be much appreciated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Who is specified as the rule actor, you another user or Automation for Jira (ootb user for automation)?
IF it is not set t Automation for Jira but you or an other user, this cold be the problem.
The Automation for Jira user has some elevated permissions that user can't get.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for your suggestions. I've tested the automation using both my own account and the "Automation for Jira" as the actor, ensuring all configurations were correct for each scenario. Unfortunately, the issue persists—automation only works when fields are visible, regardless of which actor is set.
It seems like we're facing a limitation with how Jira handles field visibility in automations. I appreciate your insights and will continue exploring possible workarounds or consider adjustments to our process to accommodate this limitation.
Thanks again for your help.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.