Confluence has been updated to ver 6.15.9. In case of any troubles, please contact infra team.

How to sync worklogs from Jira Cloud to Jira Server (both use Tempo)

 
2
1
0
Hi - I'm new to Exalate so please bear with me ;) We're using both JIRA Cloud and JIRA Server. Most data is held on JIRA Server so we would like the Tempo time (worklogs) to be synced from Cloud back to Server so we can report on it in one place. What's most important is knowing the Hours, Issue Name, Account and User. I have read the help documentation and set up a connection outbound from the Cloud end. Outgoing Sync has this code: TempoWorkLogSync.send( "OM72xP3i1IxEgUT4YR1dmAHNRXcOEw ", // that's not my real key btw replica, issue, httpClient, nodeHelper ) Incoming Sync is blank. I don't have a trigger. Triggers only seem to work for issues and sprints. So my trigger is blank. At the Server end I have a blank Outgoing Sync and Incoming Sync simply states: issue.workLogs = workLogHelper.mergeWorkLogs(issue, replica) Nothing is syncing although the Connection is Active. No issues are under sync. Is this because I don't have a trigger. How do I get it started for current and future worklogs ? Many Thanks - Andy
    CommentAdd your comment...

    3 answers

    1.  
      2
      1
      0

      In 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 (wink)

        CommentAdd your comment...
      1.  
        1
        0
        -1

        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



        1. Francis Martens (iDalko)

          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




        2. Andrew Hines

          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 (smile)

          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


        3. Francis Martens (iDalko)

          > 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


        4. Andrew Hines

          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 ..

        5. Francis Martens (iDalko)

          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?


        6. Andrew Hines

          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 .. (wink)

          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

        7. Francis Martens (iDalko)

          What version of Jira and exalate do you have?

        8. Francis Martens (iDalko)

          Good to know about the Tempo Account - kudos to your colleague

        9. Andrew Hines

          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 ?


        10. Francis Martens (iDalko)

          Looks like.


          If you retry the errors - what gives?

        11. Andrew Hines

          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




        12. Andrew Hines

          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



        CommentAdd your comment...
      2.  
        1
        0
        -1

        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


        1. An issue gets updated on Jira A
        2. Exalate turns the issue into a message using the outgoing sync processor
        3. Exalate sends the message to Jira B
        4. The exalate on Jira B receives the message
        5. The message is applied to the related issue (the twin as we call it) using the incoming sync processor

        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.


        1. Andrew Hines

          Thanks Francis - see my follow up question. Is that OK or should I post it as a new one ?


        CommentAdd your comment...