track spent time in issue description

[nnals]

hello,

first of all thank you very much for this project!

i have a question regarding this statement/problem

gtt can only track time records from notes/comments. If you start your issue or merge request with /spend [time] in its description, gtt won't take it into consideration (for now).

what's the problem with retrieving the time logged in an issue's description? and do you perhaps already have a possible approach in mind to solve this? i would also have a try to contribute the functionality myself if this is something you think makes sense.

enjoy your day,
nicolai

[kriskbx]

GitLab doesn't offer an API for time tracking right now. They don't even store the time tracking data in a separate table within the database. Time records are just comments/notes on an issue or merge request. They only store the total amount of estimate and spent on the issue table. gtt fetches those comments and parses the text. That's the whole trick.

What you could do in theory is calculating the time_spent that is stored within an issue and if there's a difference to the time spent that's calculated by parsing all the comments you could create a new time record for the user that openend the issue. But this has some downsides: GitLab changed the comment format shortly after releasing the first beta of time tracking. So there could be false records especially in older issues. And the remove time spent command will interfere with that as well.

This is bugging me as well but I can't think of a good solution until GitLab releases an API for that. Haven't kept up with the latest changes in GitLab v10 though: maybe there's a way now... I will take another look at it next week or so.

[nnals]

thanks for the detailed response. in case you find out something new please let me know. until then i don't think it would make a lot of sense to implement a solution (myself).

[kriskbx]

I just pushed a draft of what I called "Description Parsing" to the master branch (didn't released it yet though). It's not really parsing the description but rather works in the way I pointed out above: calculating the difference betwen total_time_spent and time_spent and creating a "virtual" time record. Can you check it out with your real life data and give me some feedback wether it works out for you?

[nnals]

i'm afraid my real life data is probably not suited to test your above mentioned edge cases since i just started using gitlab but i'm of course happy to test it. just give me two days.
thanks again for your work!

[zealot128]

just used the master branch, and the gtt report command fails now for me:

$ gtt report --verbose                                                                           
  Selected projects: ...
  Resolving "xxx/xxx"... ✓
  Fetching issues... ✓
  Fetching merge requests... ✓
  Merging reports... ✓
 ️️  Processing issues... ✗) [----------------------------------------] 0% - 0m left
Error: could not process issues.
TypeError: this.config is not a function
    at resolve (/xxx/gitlab-time-tracker/src/models/hasTimes.js:98:22)
    at promise.then (/xxxx/gitlab-time-tracker/src/models/hasTimes.js:97:38)
    at process._tickCallback (internal/process/next_tick.js:103:7)

The error happens in the newly added code block in hasTimes.js. The this context seems to be different than expected. No this.config() function and this.data is available on this while running from report.

[nnals]

there's a small error in line 98 of hasTimes.js. it should be

if (this.config.get('_skipDescriptionParsing') || timeSpent === this.data.time_stats.total_time_spent) return resolve();

instead of

if (this.config('_skipDescriptionParsing') || timeSpent === this.data.time_stats.total_time_spent) return resolve();

[nnals]

there is something wrong with the handling of time frames. and it's quite weird.

i compared the following commands:

[1] node ./src/gtt.js report --closed --type=group some-group --to 2017-09-08T06:00+02:00
[2] node ./src/gtt.js report --closed --type=group some-group
[3] gtt report --closed --type=group some-group --to 2017-09-08T06:00+02:00

[1] and [2] are using the master branch. [3] is version 1.6.11 installed through npm.

section TIME STATS

total estimate and spent ignore the time frame. the values for the two users are also off. and user2 has a higher value in [1] than in [2] which should be impossible.

[1]:

* total estimate: 4d 3h
* total spent: 10d 5m
* spent: 10d 5m

* user1: 6d 2h 20m
* user2: 3d 5h 45m

[2]:

* total estimate: 4d 3h
* total spent: 10d 5m
* spent: 10d 5m

* user1: 6d 3h 30m
* user2: 3d 4h 35m

[3]:

* total estimate: 3d
* total spent: 9d 50m
* spent: 8d 55m

* user1: 5d 2h 25m
* user2: 2d 6h 30m

section ISSUES

it looks like it the time frame is considered correctly.

section MERGE REQUESTS

no data here.

section ISSUES

everything looks fine except for one entry:
│ user1 │ 12.09.2017 21:28:14 │ Issue │ 73 │ 2h 30m │

---

the actual feature of your change looks like it could be working but i'm not sure since i'd like to check it in a certain time frame.
if you need more data to look into it please tell me.

[kriskbx]

there's a small error in line 98 of hasTimes.js. it should be

Oh, my bad. Sorry, I fixed it. 😄

there is something wrong with the handling of time frames. and it's quite weird.

I tracked it down and I found an issue of how I implemented the feature. In fact I ignored the --to, --from and --user completely, so the system did some pretty weird things when using those. Stupid me. I rewrote the code and pushed a new commit to the master branch. Can you check it out again?

[kriskbx]

I did quite some testing and I haven't found any issues with this feature. Please reopen it if you encounter anything.

[kriskbx]

I just release 1.7.0 including this feature.