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.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.