[API] Extend times API

[6543]

close #8833; close #8513; close #8559

• Deprecate old stuff
• add new times json struct (extend old)
• add optional user var for EditTimeOption (Feature request: set time tracking value for other user #8559)
• add remove time comment
• expose Created in EditTimeOption as optional var
• add /repos/{owner}/{repo}/issues/{index}/times
  • GET -> TrackedTimeList
  • POST <- EditTimeOption
  • DELETE (reset time on issue to 0)
• add DELETE ​/repos​/{owner}​/{repo}​/issues​/{index}​/times​/{id} to delete specific tracked tim
• update GET /repos/{owner}/{repo}/times -> TrackedTimeList
• update GET /repos/{owner}/{repo}/times/{user}
• update GET /user/times -> TrackedTimeList
• add query param for GET functions moved to: [API] times Add filters #9373
• Add Test's
  • add time with other user and creation time
  • get trackedTimeList
  • delete one time
  • reset an issue

[6543]

@noerw you had some issues about times ... any suggestions so i dont have to touch the temies-api multible times ...

I'm thinking about an /api/v1/times/... endpoint because i cant just replace old api endpoints with a different json responce :(

[noerw]

@6543 Thanks for working on this!

• Personally I'd keep the endpoints as they were until now, this follows the structure of other API features.
• I'd add RepoOwner & Repo to the struct TrackedTime struct, at least for the /user/times endpoint (as mentioned by @bobemoe earlier. This allows for client side filtering).
• +1 for DELETE endpoints

About versioning / breaking changes:

• The gitea release notes often mention breaking changes, why would this be an issue here? I guess only the Gitea frontend depends on this API, which can be adapted in the same release.
• If we need to keep the old behaviour, what about /api/v2/.../times? For what kind of change is the API versioning intended?

[6543]

@noerw gitea frontend dont depend on api the simple thing is droping old stuff lead to backwarts incompatebilety and because gitea moves forward fast ... projects who use gitea often are a litle behind the master and/or latest release ...

[6543]

@techknowlogick i think i can do it within 1.11.0 ?

[codecov-io]

Codecov Report

Merging #9200 into master will increase coverage by 0.16%.
The diff coverage is 56.33%.

@@            Coverage Diff             @@
##           master    #9200      +/-   ##
==========================================
+ Coverage   41.46%   41.63%   +0.16%     
==========================================
  Files         571      572       +1     
  Lines       75250    75571     +321     
==========================================
+ Hits        31205    31465     +260     
- Misses      40167    40202      +35     
- Partials     3878     3904      +26

Impacted Files	Coverage Δ
models/migrations/migrations.go	1.3% <ø> (ø)	⬆️
models/issue_comment.go	43.58% <ø> (ø)	⬆️
routers/repo/issue_timetrack.go	0% <0%> (ø)	⬆️
models/migrations/v115.go	0% <0%> (ø)
models/issue_milestone.go	68.17% <100%> (+0.16%)	⬆️
models/issue_list.go	66.14% <100%> (+0.08%)	⬆️
routers/api/v1/api.go	73.92% <100%> (+0.11%)	⬆️
routers/api/v1/repo/issue_tracked_time.go	45.26% <57.36%> (+45.26%)	⬆️
models/issue_tracked_time.go	61.79% <58.22%> (-5.78%)	⬇️
modules/task/migrate.go	25% <0%> (-3.95%)	⬇️
... and 8 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2401779...0366115. Read the comment docs.

[arkamar]

I am not sure if it is not to late, but I would appreciate to set/edit Created time.Time or add a new field with date attribute. It would give users a possibility to set the time to a concrete date, and it would be possible to export meaningful timelog report for some period of time (last month, this year, ... for example), similar to Redmine. It would be very beneficial from project management point of view.

[6543]

@arkamar I'll expose Created in EditTimeOption as potional feeld

[6543]

PS: as long as it is WIP all suggestins are welcome!

[bobemoe]

I too am using this to generate a time report for a specific (monthly) period.. Currently I request all time data and then my script filters out the relevant date/month, and sums up the total times for each issue and generates a csv which includes the issue title... It's not really complicated but it could be useful if some of the functionality was built into the API:

• Specify optional StartDate and EndDate so able to request only times logged within a specifc time range.
• Request totals per Issue (within the date range if specified) maybe when this is enabled the individual component times don't even need to be shown?
• Include issue title

I guess the time range would be most useful.. especially months/years later when there is LOTS of time data.

The other points are probably more use case specific?

For reference my PHP script to do this is: https://git.jhodges.co.uk/jhodges/GiteaBot-examples/src/branch/master/src/time_report.php (which also shows how I have to create the ID->Index lookeup table)

[6543]

@bobemoe

Start/Stop Date:

StartDate: Created
EndDate: StartDate + Time

Summary

Request totals per Issue: I'd like to add this but this is not posible because of backwards compatiblety :(
if this would be not the case i woudld add a different struct for timestrackList:

times: [
 .... time list ...
],
summary: time
...

Include issue title

I'll change issue_index to issue item

[6543]

INFO: Repo is removed because Issue has the information (full_name)!

{
    "created": "2019-12-06T01:58:04.160Z",
    "id": 0,
    "issue": {
      ...
      "repository": {
        "full_name": "string",
        "id": 0,
        "name": "string"
      },
      ...
  }

[bobemoe]

@6543

Start/Stop date

I'm not sure I was clear in the original request, but what I mean was to add the start/end date to the API request, looking at the code it may go into FindTrackedTimesOptions as to act like a filter, so I could do something like:

"POST /repos/{owner}/{repo}/times" DATA: {"startDate":"2019-11-01","endDate":"2019-11-30"}

This would return only time data that fell into that range. Something like (excuse my syntax ;)

TrackedTime.Created >= FindTrackedTimesOptions.startDate &&
TrackedTime.Created <= FindTrackedTimesOptions.endDate

Summary

Shame it breaks BC. Maybe another API endpoint for reporting? Could have a lot more complex features included. Would be outside the scope of this PR I expect.

Include Issue

Including the full Issue looks great, I can get the title and repo etc :) Saves a lot of extra requests for my reporting script. My concern would be the size of the API response, especially when there are hundreds/thousands of TrackedTime data. I don't think there is pagination at the moment? Allowing the start/end date filter (as above) would reduce that as it acts as a kind of pagination in itself anyway.

Build and Test

Cant wait to give it a shot :) Thanks for your work

[bobemoe]

@6543 how come deprecate /repos/{owner}/{repo}/times/{user} in favour of /repos/{owner}/{repo}/times? This means I can no longer get times for a specific user. Will user be added to the request parameters of /repos/{owner}/{repo}/times to be able to filter out just times for a specific user?

[6543]

@zeripath found working solution link

opts.ToSession(e).Table("tracked_time").Cols("deleted").Update(&TrackedTime{Deleted: true})

if I specify Table and then Colum it works :D

xorm SetExpr can only use string link

[6543]

@techknowlogick you dont have to look for a solution anymore

[6543]

@lunny i added /modules/indexer/code/bleve.index/ to gitignore - it apeared after one of your code-refactors are you ok with it? (dont like to make a one line PR)

[6543]

ready to merge 🚀

[zeripath]

@6543 could you remove the line from .gitignore and re-push - for some reason I cannot push to this branch on your repo.

[6543]

@zeripath added your suggestion and added you to maintainer of my fork for later changes ...

[6543]

ready to merge 🚀

[zeripath]

make lg-tm work