Andrew HinesIn fact Juan from your support desk gave us the mssing information needed to properly match Accounts.
Check out answer here : How to set Tempo account on Jira Server
Thanks to you and Juan for all assistance 
Thank you Francis. I now have it syncing the Issues as well but I am having a problem specifying the user between the two systems.
I initially got error
Exalate failed to merge worklogs via workLogHelper.mergeWorklogs(issue, replica). User by email: is.origo.jira.tempo-plugin@connect.atlassian.com was not found. Please create user with this email.
If you don't want to create that user, please use workLogHelper.mergeWorkLogs(issue, replica, { w -> w.author = /* get a user on your side via either of the methods in the nodeHelper e.g. nodeHelper.getUserByDisplayName() */ })
I understand this is because it hasn't matched users properly. I's like to match on email address and I first made my email address publicly visible on JIRA Cloud. Same result.
Then I also changed the inbound code on JIRA server as below:
issue.workLogs = workLogHelper.mergeWorkLogs(issue,replica, { w ->
w.author = nodeHelper.getUserByEmail(userMapping[w.author?.key]) ?: w.author
w.updateAuthor = nodeHelper.getUserByEmail(userMapping[w.updateAuthor?.key]) ?: w.updateAuthor
})
then I get error
Script error details: No such property: userMapping for class: Script196. Error line: Script196.groovy:9
What is the correct way to specify the user lookup by email on JIRA Server? Tempo is on both Cloud and Server if that's relevant.
Many Thanks - Andy
You are almost there
a) You need to define a user mapping. Something like
def userMapping = [
"foo@google.com" : "bar@facebook.com",
"xyz@dropbox.com" : "wvu@bitcoin.com",
]
def targetMail = userMapping["xyz@dropbox.com"]
// targetMail is "wvu@bitcoin.com"
But - make sure that the w.author?.key is provided.
You can test this by inspecting the remote issues tab on the issue or by throwing an exception in the incoming sync on the server
throw new Exception("The original author is ${w.author?.key}")
Whenever a new message is received from the cloud, an error will be raised with that content
Check for more information the troubleshooting article
Hi Francis ...
Thank you. In fact I got it to work as follows :
On the source side (JIRA Cloud) I added a line to set the replica assignee
On the destination side (JIRA Server) I used the replica assignee email to getUserByEmail
That synced my Issue and I was initially very happy 
Then I realised I still had a couple of issues - sorry
(1) The Account field doesn't sync. Do you have any examples where the Account is copied across. We use this for project codes for Finance. I appreciate that it is a Tempo specific field - not native Jira.
(2) I realise that I'm wrong to search for the issue.assignee when attributing worklogs. It should be the person booking the time, not the owner of the Issue. What field should I have used ? We will have the same users (by email) on both systems.
Many Thanks for your help - Andy
> The Account field doesn't sync.
This is not supported in the TempoWorkLogSync. TempoWorkLogSync is meant to sync Tempo Worklogs and is provided as an example. The logic for accounts should be similar. Maybe someone else already made such logic
> Worklog attribution
Check the details in following document
https://docs.idalko.com/exalate/x/DgBL
In line 9 in the code example above - change replica.assignee.email into w.author?.email
This should be sufficient
Let me know how it goes
Hi Francis - Thanks so much for your help. It is very much appreciated. Using w.author?.email worked and now my worklogs sync from Cloud to Server with the correct user. That's the basics of what I was trying to do.
So now my biggest sticking point is the Account field. I believe that it's not part of the worklog itself but is linked to it - is that right ? Is there any function I can use which will set the Account for a Tempo worklog in JIRA Server. I know the custom field names at either end but I don't know how to set them when I do the workLogHelper.mergeWorkLogs.
Also if this is something that would warrant a commercial discussion rather than me floundering around you providing free help then please say so. We are on an Exalate trial but will iminently be going to a paid subscription so happy to have a chat ..
This needs to be developed. We got a lot on our stack atm, so it is not in our plans.
Can you have a look if no one else did it?
Hi Francis .. thanks for your help. It seems I also have a great team working for me. One of my colleagues came up with the following solution :
Outbound from JIRA Cloud:
Inbound in JIRA Server :
This works when we test it with a new Issue and then log time to it. the Account gets synced with the Issue and worklogs inherit that Account.
Cue .. happy dancing around the room ..
When we update the Connection to sync our live JSD Cloud back to a custom Jira Server project we get one of two errors...
Most errors are the first one.
Any pointers ? Do we need the same workflow and transitions on both sides ?
Thanks - Andy
What version of Jira and exalate do you have?
Good to know about the Tempo Account - kudos to your colleague
Hi Francis -
JIRA Cloud uses Exalate v5.0.44 (Core v5.0.52)
JIRA Server (v8.2.3) uses v4.7.9-j8
Are they all good ?
Looks like.
If you retry the errors - what gives?
Hi Francis - I get the same error. Here's the details:
We have gone back to syncing a very basic project - absolutely standard workflow.
We've updated the receiving script as follows :
If we comment out line 12 then it syncs and we can see that the value being passed in replica.customFields."Account" is :
Experimentation confirms that this is the Description of the Account and not the Key.
If we uncomment line 12 then it fails with the above error.
Any suggestions - or resources you can point us to ?
Thanks - Andy
Hi - I'm now trying to code a fixed value to the customfield that is used by the Account but I'm not getting the syntax right.
I could use this as a workaround for now ...
On our JIRA Server customfield 16030 holds the account details. I'm seeing this via a REST API call
If I try to set this field though then it fails. I'm using :
issue.customFields."16030".value = [self: "https://cds.vixtechnology.com/rest/tempo-accounts/1/account/220", id: 220, key: "OVERHEAD", name: "OVERHEAD"]
How would I express this properly ? If I try it on a different custom field then it works but it shows as one long string.
So clearly I am getting the syntax wrong and not expressing it as 4 element associative array. I assume this is why it's not able to be set.
Hopefully this is just my lack of understanding .. any ideas ?
Many Thanks - Andy
Welcome to the Exalate, and thanks for asking the question.
The way that Exalate works is documented in the synchronization process, but it boils down to
To be able to sync worklogs, you need to have the issue - containing these worklogs - to be under sync.
Else Exalate will not know to what issue the worklogs need to be added at the receiving end.
We tweaked the documentation a bit so that it is hopefully more clear (here)
Triggers are not necessary as you can also Exalate manually. But most customers are configuring a trigger.
Thanks Francis - see my follow up question. Is that OK or should I post it as a new one ?
that's ok