TL;DR: Is there something about the Manual trigger that provides more access to information about the issue, as compared to the Issue Updated trigger?
Details:
I'm trying to set up a Automation for Jira (Server) rule to run whenever a field is updated. Because it is a field type created by the Secure Fields add-on, I had to manually configure it to post an "Issue Updated" event; they do not do so by default, and the developers of that add-on said they don't post the field's value in the event data by design. But that should be ok for my purposes.
I built the automation rule using the Manual trigger for testing, and reading the value of the secure field in question via the smart value {{customfield_10925.value}} works fine; I output the value to the audit log right at the start of the rule.
I switched the rule over to the "Issue Updated" trigger, then changed the value of that field in an issue. In the audit log, I can see that the rule was triggered, but the value I'm writing to the log for the custom field value is blank/empty.
Any ideas why that might be happening? I appreciate your time and assistance!
UPDATE:
I have discovered that reading & logging the secure-field value based on the "Issue Updated" trigger works fine when a built-in field type value is updated, but the value is still read as empty/null when the value of any secure field is updated. I don't really understand how/why that could be, when I can still read other things about the issue in both cases (e.g. {{issue.properties.PrevFieldValue}} that I set earlier), so clearly I have access to the correct issue in both cases.
I am working with Coresoftlabs, the makers of the Secure Fields add-on, but no luck yet, so I still appreciate any suggestions any of you might have!
Hi @Joe Morris
From what you describe of the data being available with the manual trigger and not available with the issue updated trigger, I wonder if it is one of two issues: the API doesn't have the data or a racetrack condition where it isn't loaded yet.
If it is the API, you probably cannot do anything about it until your add-on vendor works with Atlassian to improve it. (Although, I guess you could possibly work-around with a web request to the REST API to update the issue... seems hackery.)
For the racetrack condition, you could try adding a Re-fetch action after the trigger. That would slow down the rule and reload the data before you try to access it.
Best regards,
Bill
Wow, fantastic suggestion @Bill Sheboy! It turned out to be a race condition; adding a "Re-fetch issue data" at the top resolved the problem, and now the values are all being logged correctly.
Thank you again for your help!
-Joe
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.