ahungry / org-jira

Bring Jira and OrgMode together
680 stars 130 forks source link

LOGBOOK - Worklogs sync #320

Closed lelit closed 1 year ago

lelit commented 1 year ago

I notice some differences between Jira worklog and Org logbook after repeated syncs.

A bit of context: until now (or more exactly, until I discovered org-jira some days ago) I used track the time I spent on various issues in a plain Org file. Since some of them are intertwined, I have a structure like the following:

* March 2023

** Issue PROJ-42
:LOGBOOK:
CLOCK: [2023-03-23 gio 16:38]--[2023-03-23 gio 17:57] =>  1:19
CLOCK: [2023-03-23 gio 10:33]--[2023-03-23 gio 11:33] =>  1:00
CLOCK: [2023-03-22 mer 16:28]--[2023-03-22 mer 20:06] =>  3:38
CLOCK: [2023-03-17 ven 09:56]--[2023-03-17 ven 11:22] =>  1:26
CLOCK: [2023-03-16 gio 17:35]--[2023-03-16 gio 19:24] =>  1:49
:END:

** Issue PROJ-43
:LOGBOOK:
CLOCK: [2023-03-23 gio 11:41]--[2023-03-23 gio 12:30] =>  0:49
:END:

Experimenting with org-jira, I first fetched all my issues with org-jira-get-issues and then I copied those LOGBOOK in the various issue collected in the resulting PROJ.org.

Doing a first org-jira-update-worklogs-from-org-clocks, the LOGBOOK for PROJ-42 (inside the new PROJ.org managed by org-jira) changed to the following:

:LOGBOOK:
CLOCK: [2023-03-23 gio 00:00]--[2023-03-23 gio 01:19] =>  1:19
  :id: 29145
CLOCK: [2023-03-23 gio 00:00]--[2023-03-23 gio 01:00] =>  1:00
  :id: 29146
CLOCK: [2023-03-22 mer 00:00]--[2023-03-22 mer 03:38] =>  3:38
  :id: 29147
CLOCK: [2023-03-17 ven 00:00]--[2023-03-17 ven 01:26] =>  1:26
  :id: 29148
CLOCK: [2023-03-16 gio 00:00]--[2023-03-16 gio 01:49] =>  1:49
  :id: 29149
:END:

where you can see that all those intervals were shifted to the start of the day, although on the Jira instance I see the original hours (slightly edited for compactness):

lele logged work - 16/03/2023 17:35
    Time Spent:
        1h 49m
        <No comment>

lele logged work - 17/03/2023 09:56
    Time Spent:
        1h 26m
        <No comment>
...

If I now register some more work on that issue, for example:

:LOGBOOK:
CLOCK: [2023-03-24 ven 11:00]--[2023-03-24 ven 11:20] =>  0:20
CLOCK: [2023-03-23 gio 00:00]--[2023-03-23 gio 01:19] =>  1:19
  :id: 29145
CLOCK: [2023-03-23 gio 00:00]--[2023-03-23 gio 01:00] =>  1:00
  :id: 29146
CLOCK: [2023-03-22 mer 00:00]--[2023-03-22 mer 03:38] =>  3:38
  :id: 29147
CLOCK: [2023-03-17 ven 00:00]--[2023-03-17 ven 01:26] =>  1:26
  :id: 29148
CLOCK: [2023-03-16 gio 00:00]--[2023-03-16 gio 01:49] =>  1:49
  :id: 29149
:END:

then, re-executing org-jira-update-worklogs-from-org-clocks, I end up with the following in PROJ.org:

:LOGBOOK:
CLOCK: [2023-03-24 ven 00:00]--[2023-03-24 ven 00:20] =>  0:20
  :id: 29150
CLOCK: [2023-03-23 gio 00:00]--[2023-03-23 gio 01:19] =>  1:19
  :id: 29145
CLOCK: [2023-03-23 gio 00:00]--[2023-03-23 gio 01:00] =>  1:00
  :id: 29146
CLOCK: [2023-03-22 mer 00:00]--[2023-03-22 mer 03:38] =>  3:38
  :id: 29147
CLOCK: [2023-03-17 ven 00:00]--[2023-03-17 ven 01:26] =>  1:26
  :id: 29148
CLOCK: [2023-03-16 gio 00:00]--[2023-03-16 gio 01:49] =>  1:49
  :id: 29149
:END:

while on Jira I see this:

...
lele logged work - 23/03/2023 00:00 - edited
    Time Spent:
        1h 19m
        <No comment>

lele logged work - 23/03/2023 00:00 - edited
    Time Spent:
        1h
        <No comment>

lele logged work - 24/03/2023 11:00
    Time Spent:
        20m
        <No comment>

that is, the existing entries where updated (edited) loosing the correct time, while the new one for today carries the original time.

This is not a big problem of course, as I assume what matters for my customer is the actual sum of hours spent on a given issue and not when I did the actual work, but I wonder if this rings any bell to you, and if it can be rectified.

I'm still trying to figure out my own way of using org-jira, and I guess that, at least for a while, I will keep updating my original "plain" Org file, and now and then I will manually copy new CLOCK lines from there to the PROJ.org file eventually updating Jira. That would be simpler and less error prone if the time-of-the-day between the two matches, but all in all org-jira will surely take away the boringness of thru-the-web editing of Jira worklogs.

Thanks in advance for any hint (and for org-jira :heart:).

lelit commented 1 year ago

I tried to investigate and I think I am on something!

When org-jira-update-worklogs-from-org-clocks has done its main job it calls org-jira-update-worklogs-for-issue to refresh the LOGBOOK of the issue.

Down a couple of levels, there are calls to org-jira-date-to-org-clock, that for some reason explicitly calls org-jira-date-strip-letter-t....

So what's happening is this:

  1. the Jira worklogs contains an ISO8601 started timestamp, say "2023-02-14T19:01:00.000+0100"

  2. that's converted to a timestamp

    (org-jira-date-strip-letter-t "2023-02-14T19:01:00.000+0100") => "2023-02-14 19:01:00+0100" (date-to-time "2023-02-14 19:01:00+0100") => (25578 49392)

  3. and back to an org clock

    (org-jira-time-stamp-to-org-clock '(25578 49392)) => "2023-02-14 mar 00:00"

where the time-of-the-day part is lost.

The problem apparently is in that call to org-jira-date-strip-letter-t: omitting that we have

(date-to-time "2023-02-14T19:01:00.000+0100") => (25579 52316)

(org-jira-time-stamp-to-org-clock '(25579 52316)) => "2023-02-14 mar 19:01"
lelit commented 1 year ago

I have done some more tests, and can confirm that redefining the org-jira-date-to-org-clock as

(defun org-jira-date-to-org-clock (date)
  "Convert DATE into a time stamp and then into org-clock format.
Expects a date in format such as: 2017-02-26T00:08:00.000-0500."
  (org-jira-time-stamp-to-org-clock (date-to-time date)))

the roundtrip works as expected, that is on Jira's worklogs I see the corrected timestamps, and at the end of org-jira-update-worklogs-from-org-clocks the only modifications on the Org's logbook are the backported :id: of each entry.

I'm using Emacs master, and accordingly to date-to-time documentation it is already able to parse an ISO-8601 timestamp: the oldest Emacs around me is Emacs 28, and this seems to work on that version as well.

ahungry commented 1 year ago

Interesting - I remember writing the code to handle removal of the T, but of course, in hindsight (and in commit messages) I can't figure out exactly "why" it was needed.

It was definitely solving something at one point, but seems to no longer be necessary...

Did you want to make a PR with this change?

lelit commented 1 year ago

in hindsight (and in commit messages) I can't figure out exactly "why" it was needed.

Maybe for some very old Emacs version?

Did you want to make a PR with this change?

Sure, I'll do that promptly.

ahungry commented 1 year ago

All set, thanks!