Why can I read a field value with Manual trigger but not Issue Updated trigger?

Joe Morris_0ztglk

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!

Bill Sheboy

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