Jira Automation: change custom field to the current/initiating user

[Mignonne Yap]

UPDATE: I ended up using a post function.

I have a custom field for single user picker called 'Tester' and I'd like to have this field update to the user who transitions the Jira issue from one status to another.

This used to work for our setup up until a few days ago:

{
"fields": {
"tester": { "id": "{{initiator.accountId}}" }
}
}

Now I get an error: "Additional fields contains invalid field(s) in 'update' or 'fields' section: tester"

I've found some other 'solutions' (including editing 'fields' to 'field') that were reported successful in the audit log of the automation but the change does not reflect on the actual issue.

I've also tried waiting after some time to re-trigger the automation (as sometimes Jira's slow to cascading changes) but still nothing. 

Help me, Jira users. You're my only hope.

[John Funk · Accepted solution]

Hi Mignonne,

I would verify that the Tester field is still on the Edit screen and that the Context for the Tester custom field has not changed - is still available for the project and issue type that you are using for this issue. 

[Mignonne Yap]

Hi John,

What do you mean by Edit screen? There have been no changes to any of the settings; the field is shown on the 'Configure screen' as well as when I view an issue/user story and the context is the same 'This field will be available on issues of any type in all projects'.

[John Funk]

Maybe try to edit the issue manually just like the automation rule would do and see if there is any problem with that. 

[Mignonne Yap]

I'm able to edit the custom field of my sample Jira issue without any issue. I need to start typing a name for my options to show up. I can choose from there and update the field.

[John Funk]

Can you share the entire rule that you have? 

And since it might be a timing issue, you can try to put in an action to do a Re-fetch prior to the field being updated. That's the only way to "delay" the automation from firing that part. 

[Mignonne Yap]

When: Issue transitioned from 'Ready for QA' to 'In QA'

Then: Re-fetch issue data

And: Edit issue fields 'Tester' (custom User Picker (single user) field that is displayed on the Jira issue and is editable)

• Choose fields to set: Tester
• Additional fields:
  {
  "field": {
  "Tester": [{ "id": "{{initiator.accountID}}" }]
  }
  }

No error upon saving and audit logs report action was successful but no change when the Jira issue is viewed immediately after, minutes, hours and even days after the action was triggered.

Re: And since it might be a timing issue, you can try to put in an action to do a Re-fetch prior to the field being updated. That's the only way to "delay" the automation from firing that part. 

I added this action and retested it. Still no luck. It doesn't seem to be a timing issue, though. :(

[John Funk]

Maybe add some log actions to see what value is being set. 

[Mignonne Yap]

I've added some log actions but I'm not sure if I'm doing it right as no values are returned when I view an audit log:

[John Funk]

I would add the log action before the Edit Issue fields step. And capture the initiator. 

[Mignonne Yap]

What do you mean by initiator and how do I capture this? I checked Jira's documentation - https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#Available-properties.1 and only found {{approval.initiator}}.

Is this correct?

[Mignonne Yap]

Still no change on the actual ticket :( 

[John Funk]

No, try {{issue.initiator.acctID}} in the log function to see if that brings something back. 

[Mignonne Yap]

Thanks for this. Unfortunately it isn't returning anything:

[John Funk]

Well, that's really weird.

Is there any reason that the Assignee can't be set to the person who moved the card? 

And then maybe update the Tester field by copying it from the Assignee field. 

[Mignonne Yap]

Unfortunately we'd like to keep the Assignee field to the developer who worked on the issue... unless I create another custom field for the developer with a similar automation but then I'd likely run in the same issue with this field not updating either. :( 

[Mignonne Yap]

I tried it all the same and it's still not reflecting on the actual Jira issue, despite what the audit log says:

Audit logs (but the actual Jira issue's custom field was not updated to match the new Assignee).

[John Funk]

Did it actually assign it to the Initiator? 

If so, then you might want to put in a Re-fetch action after the Assign issue step to give the system time to make that change first. 

[Mignonne Yap]

Yes, the assignee correctly updated as soon as the issue transitioned to the correct status, but the custom field did not copy the value from the 'assignee' field.

[John Funk]

Then definitely try the Re-fetch in between them.

[Mignonne Yap]

Unfortunately, it still didn't update.

[John Funk]

Can you share the details from the last step? 

[Mignonne Yap]

Sure, all the grayed out fields just show the Jira issue number/ID of the issue that I tested by transitioning from and to the statuses indicated in the automation. The custom field on the actual issue/ticket remained unchanged though.

[Mignonne Yap]

Sorry, I forgot to specify in the last step that it should update the custom field based on the assignee. I tried it this time but it's not reflecting on the actual Jira issue, despite the success reported on the audit log:

[John Funk]

Okay, why are you doing it as an advanced option? Just click the three dots beside the Tester field above and choose Copy from.

Then choose Assignee as the field to copy from. 

[Mignonne Yap]

Thanks! That worked to update my custom field based on the assignee. But I couldn't figure out how to then change the Assignee back to the previous assignee through automation.

Instead I found another way to achieve my end goal by using a post-function that updates my custom field based on the user who did the transition.

Thank you so much for your help and patience!

[John Funk]

Awesome! I am so glad you were able to get it all worked out!

[Eloise Taylor]

I'm getting the same error with a similar use-case.  In my scenario I can't select the field from the drop-down because it's a custom field.   My custom field is called "Original Developer"

{
  "fields": {
    "Original Developer": [{ "id": "{{initiator.accountId}}" }]
   }
}

It was working well for months, but then started failing recently.  I hadn't made any changes to the config, it just started failing.  

Additional fields contains invalid field(s) in 'update' or 'fields' 
section: Original Developer