Hi Jonathon Irwin
You can extract the valid on timestamp from the replica
(This is the timestamp when the replica has been built)
An example can be
def sdf = new java.text.SimpleDateFormat("yyyy-MMM-dd HH:mm:ss")
def validOnTS = syncRequest.replica?.validOn?.timeMillis
def validOnDate = sdf.format(validOnTS)
debug.error("validOnDate = ${validOnDate}")
Would this tell me the current sync time or the last sync time (previous outbound)? And would it work on the firstSync?
This will tell when the replica has been created (on the other side)
So changes in the history applied on the local issue after that moment could get priority, and updates to these fields can then be ignored.
Oh this would be on the Incoming Sync side? And that would be the current, which is fine for excluding changes since then from being overwritten, but doesn't allow obtaining changes (from source side) since the previous one. Unless we could do the same with the 'previous' replica value that is seen on the destination? Or can it also be seen on the Outgoing sync (best case)?
So to elaborate, in Outgoing sync I want something like (whether by using REST API for cloud or ChangeHistories in Server):
def ChangedFields = [ : ]
def sdf = new java.text.SimpleDateFormat("yyyy-MMM-dd HH:mm:ss")
def validOnTS = syncRequest.previous?.validOn?.timeMillis // if previous exists in outgoing?
def lastOutgoingSync = sdf.format(validOnTS)
...
//Get Changed fields using method (getChangesSince(issue, lastOutgoingSync) or loop through paginated Change History Rest call for entries after that time
replica.customKeys.ChangedFields = ChangedFields
Then on incoming:
// Obtain changelog for localIssue as alternative method to above (cloud/server method) but instead using replica's time as the bound since and instead of adding to the map, remove the key/field if its a newer change
for (field in replica.customKeys.ChangedFields) {
issue.customFields."${field}".value = replica.customFields."${field}"?.value //with extra if checks and mapping to convert to right fields for this instance + account for system fields
}
To minimise information exposed in Outbound synchronisation and prevent overwriting edits that have either not been received yet or occurred after the current sync event going outbound on the receiving end, it would be useful to be able to reference this value for calling the ChangeHistory value (on server) or searching the Change History REST API results on cloud Jira. It would also potentially (if it clears on unexalate) allow detection of firstSync from cloud outbound rather than just Server.