As the Exalate Sync is triggered by an issue event in Jira Cloud/Server, is there any way to access the information from the event in an outbound sync script? This has applications in not having to search the ticket change history (since Edit events have a changelog already as a property), being able to determine if the sync shouldn’t occur (based on event type and scenario of use). I realise it’s a listener that would trigger the exalate to occur but just checking in case it’s something I could access.
Answer by Francis Martens (Exalate) on 22 February 2021
Hi Jonathon Irwin
This is currently not exposed.
Can you elaborate on the use case?
Comments:
Jonathon Irwin commented on 22 February 2021
Certainly. Under the assumption that all events (or at least all Edit events) of the ticket trigger an Exalate sync within both Server and Cloud Jira, having access to the Event’s properties (https://docs.atlassian.com/software/jira/docs/api/7.6.1/com/atlassian/jira/event/issue/IssueEvent.html) would allow accessing only those fields which were changed so they are the only ones overwritten on the destination instance, since (at least in the behind firewall configuration) it can take ~1 minute for the sync to reach and be written to the destination due to polling times and other factors.
It would also allow access to whether a comment was made during that event.
If it isn’t safe to assume that all Edit events trigger syncs then that is less valid and a search still needs to be done of the ChangeHistory since last outbound to ensure nothing is missed.
Francis Martens (Exalate) commented on 22 February 2021
Would the change history not be sufficient?
Jonathon Irwin commented on 22 February 2021
Functionally it is sufficient, but it does require a separate call using a component manager+ in the case of cloud potentially multiple rest calls to obtain the latest (since it starts at the oldest entries first) changes. The event is more for the purposes of cutting out this need to lookup the whole history and instead just grab the changes for this event which caused the sync to happen. Also allowing for any delay in the outgoing trigger accessing this information (e.g. if event occurs, but in the few seconds between triggering and outgoing script another automation occurs changing a value, just grabbing the latest change would be the wrong one since that would have its own sync). It also means we could just return in the event fields we don’t care about for this connection occur are changed.
Francis Martens (Exalate) commented on 23 February 2021
Interesting to know how multi threads changing the same issue reflects into the replica.
My current assumption is that when the event listener kicks in, the issue referenced by the event is fully cached.
Changes applied by other thread will only reflect when the cache is refreshed - but this would require a db roundtrip.