Why tempo move worklog delete the worklog and create a new one ?

[Vcabourdin]

We use the tempo rest api to get the worklogs in an external application.

We noticed that when we move a worklog to another issue, the moved worklog is in fact deleted and a new one is created (new id).

In in our system we have now two worklogs that refers to the same work... I know we can do a diff and delete worklogs in our system that are not anymore in jira but in this case we have to request all jira worklogs since the begining of times and not for a period since the last import.

Do we have misunderstood the functionnality ? Or why the worklog is deleted instead of just updated with the new issueid ?

Can we block the move worklog functionality ?

[Bjarni Thorbjornsson · Accepted solution]

Hi,

The usual way to integrate Tempo to external systems is to use both the "getWorklog" and "updateWorklog" services. "updateWorklog" is used to tell Tempo that an external system has accepted the worklog and that means that if you move or delete a worklog the external system will be notified about the "delete", i.e. you would get two records after the move: a new worklog and a "zero" worklog for the delete.

I hope this clarifies the issue. Here is a blog I wrote some time ago regarding the integration: http://blog.tempoplugin.com/2011/integrating-atlassian-jira-using-tempo-plugin-part-1/

Best regards,

Bjarni

[Vcabourdin]

Thank you, it's exactly what we needed!

[Daniel Harvey]

Bjarni, In relation to moved worklogs I was expecting that the external ID would "move" with the moved worklog. What I appear to see is that the deleted worklog is visible and retains the external ID but the new "moved" worklog does not contain the external ID. I expect the external ID to move so that we could track the continuity of the "moved" worklog. Please advise. Thanks, Daniel

[Bjarni Thorbjornsson]

Hi Daniel, Move is basically delete+create and that is what you get in the API: delete of the old and create of new. There is no history of the origin of the worklogs. Hope this helps, -Bjarni

[Daniel Harvey]

Can the external ID not be transferred so that what is described to the user as a "move" may actually be have some continuity?

[Daniel Harvey]

PS Thanks for the prompt reply.

[Daniel Harvey]

Hi Bjarni, Can you please provide some advice please. We implemented the update worklogs using our external IDs purely for tracking "moved" worklogs. It is critical for us to be able to track the "move" operation. Here is the scenario: 1. Worklog entered. 2. Staff member paid (fortnightly cycle). 3. Worklog moved as part of the billing process (monthly cycle). After 3, we have a "paid" but "deleted" worklog which I must be able to match with the "moved" worklog otherwise I cannot determine which of the "moved" worklogs are unpaid to the staff member. This is very important. Please advise. Thanks, Daniel

[Bjarni Thorbjornsson]

Hi Daniel, The JIRA API does not support a direct "move", that is why we do a "delete+create". You do get a notification of the deleted worklog in the API, you should therefore be able to match the new and the old based on the data (username+date+issue+hours). BTW: how do you move the worklogs at the end of the month and why? -Bjarni

[Daniel Harvey]

Hi Bjarni, In relation to your suggestion of matching: Yes, this is *sometimes* possible. However, if the worklog is "moved" and then any of the fields you mention (username+date+issue+hours) are modified then the match becomes difficult. Given that the sync process runs at regular intervals, there are often problems matching - particularly given than the "move" and any corrections to the fields are made at the same time. Is there no way you can set the existing external ID into the "created" worklog after the "move"? Any other ideas? In relation to your question: Staff are paid on a fortnightly cycle, but many of our clients are billed either on the alternate fortnight or monthly. At billing time allocations are checked and where errors are identified, the worklogs are "moved" to the correct issue. Your help is appreciated. - Daniel

[Daniel Harvey]

Bjarni, Any other ideas on this? Thanks, Daniel