Automation to add watchers based on changed custom user field

Question

See audit log below.

When I iterate over my custom user ield, I can add everyone as watchers. However it's possible someone who is in the POC field explicitly unwatched this ticket before, so I don't want to re-add every POC on field change - just the deltas.

It looks like the smartValue for fieldChange is enclosed in brackets, which messes it up(?). Not sure if I'm doing something wrong here; I've tried passing in the {{fieldChange.to}} object directly (vs. iterating over it), and it seems like the dang nab array notation is confusing it :)

Bill Sheboy · Answer

Yes, and...As JPD projects seem based upon team-managed projects, and those use those pesky "People" fields that have lots of rule problems, it may not yet be possible to do those notifications.

Tim Feeley · Answer

Thanks Bill :-)

I'll give it a shot. I only used the two branches to examine the values for each, not as a requirement for real; thanks for the reminder! Will give it a shot.

For Atlassian: My use case would be more directly solved if JIRA (Discovery Board) let me specify userlist fields as a target for notifications - or if "Watchers" was a better integrated field in the grid :)

Bill Sheboy · Answer

Hi @Tim Feeley -- Welcome to the Atlassian Community!

Yes, that inconsistency in rules using arrays versus lists is challenging.  Often the work-around is to strip off the square brackets with text functions, and then use split() and trim() to convert into a list.

You do not show the details of your advanced branch values, and I suspect you are using the delta-value smart values for fieldChange: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--fieldChange--

Please note there are quite a few typos in that particular section of the documentation and so you may need to experiment to find the correct smart values.

If not, perhaps try those to get only the adds and deletes for specific changes.

Also please note: the rule you show is using two different advanced branches, which could be on more than one value for each.  Any rule branches which could be on more than one thing are run asynchronously and in parallel.  Please take that into account in your rule as that may lead to unexpected results.

I recall suggesting an alternative to this approach a couple of years ago, using created variables to gather up the watchers to add and remove, and then making one single update using advanced edit with JSON.

Kind regards,
Bill