Feature Request: Expose Time Tracker Start and Stop in API #2854

New Issue

GiteaMirror · 2025-11-02T04:51:33-06:00

GiteaMirror commented

2025-11-02 04:51:33 -06:00

Originally created by @ekrgb on GitHub (Feb 3, 2019).

Gitea version (or commit ref): 1.7.1 (Docker image from Docker Hub)
Git version: N/A
Operating system: openSuSE Leap 15.0
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:
N/A

Description

While it is possible to add time to an issue, it is not possible to trigger the functionality to start or stop logging time on an issue as it is provided by the Web Interface (see screen below) via API (in accordance to /api/swagger in version 1.7.1).

By this feature request I want to suggest to expose this functionality via API as well - including the ability to query if time us currently tracked ("Start" was issued but no "Stop" yet) or not.

Thank you very much for considering this feature request.

Background

Concrete Personal Example

Just my personal issue which would be solved by the implementation of this request:

We are managing our tasks and issues via the "issues functionality" in Gitea, which is working very well for us. By doing so, we also use the "Start" and "Stop" time tracking functionality via the Gitea Web Interface (which seems to had been introduced by #967) which comes very handy.

One issue with that is, that when an Gitea issue is closed by mentioning it in the commit comment or pull request (see #462), the time tracking is not stopped. That for itself would not be a problem as a web hook could be registered for issue changes and when called an API call could be issued to stop the time tracking on the issue - if such an API call would be available.

I would suggest not to change the behaviour when the issue is closed by mentioning it in the commit comment or pull request, as this would allow the maximum flexibility but to allow for automation like outlined above it would be necessary to have the "Start/Stop" functionality exposed via API.

In General

In general I believe it would make a lot of sense to expose the "Start/Stop" functionality exposed via API as there could be a number of scenarios where this would allow automation for more efficient handling of issues in Gitea.

Screenshots

Time Tracker in UI for Reference

Originally created by @ekrgb on GitHub (Feb 3, 2019).  - Gitea version (or commit ref): 1.7.1 (Docker image from Docker Hub) - Git version: N/A - Operating system: openSuSE Leap 15.0 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: N/A ## Description While it is possible to add time to an issue, it is not possible to trigger the functionality to start or stop logging time on an issue as it is provided by the Web Interface (see screen below) via API (in accordance to _/api/swagger_ in version 1.7.1). By this feature request I want to suggest to expose this functionality via API as well - including the ability to query if time us currently tracked ("Start" was issued but no "Stop" yet) or not. Thank you very much for considering this feature request. ## Background ### Concrete Personal Example Just my personal issue which would be solved by the implementation of this request: We are managing our tasks and issues via the "issues functionality" in Gitea, which is working very well for us. By doing so, we also use the "Start" and "Stop" time tracking functionality via the Gitea Web Interface (which seems to had been introduced by #967) which comes very handy. One issue with that is, that when an Gitea issue is closed by mentioning it in the commit comment or pull request (see #462), the time tracking is not stopped. That for itself would not be a problem as a web hook could be registered for issue changes and when called an API call could be issued to stop the time tracking on the issue - if such an API call would be available. I would suggest not to change the behaviour when the issue is closed by mentioning it in the commit comment or pull request, as this would allow the maximum flexibility but to allow for automation like outlined above it would be necessary to have the "Start/Stop" functionality exposed via API. ### In General In general I believe it would make a lot of sense to expose the "Start/Stop" functionality exposed via API as there could be a number of scenarios where this would allow automation for more efficient handling of issues in Gitea. ## Screenshots ### Time Tracker in UI for Reference ![image](https://user-images.githubusercontent.com/47088110/52174785-5b7e6380-2799-11e9-86a7-2a394b67ed0a.png)

GiteaMirror added the type/proposal modifies/api labels 2025-11-02 04:51:33 -06:00

GiteaMirror closed this issue

2025-11-02 04:51:33 -06:00

GiteaMirror commented

2025-11-02 04:51:34 -06:00

@adelowo commented on GitHub (Feb 5, 2019):

While this is nice, in the meantime while we wait on the PR for an API, I will update https://github.com/go-gitea/gitea/pull/4327 to take issues that are closed via commits into account too

@adelowo commented on GitHub (Feb 5, 2019): While this is nice, in the meantime while we wait on the PR for an API, I will update https://github.com/go-gitea/gitea/pull/4327 to take issues that are closed via commits into account too

GiteaMirror commented

2025-11-02 04:51:34 -06:00

@adelowo commented on GitHub (Feb 5, 2019):

@ekrgb #4327 has been merged so the root cause of this issue should be fixed.
The Stopwatch will be stopped whenever an issue is closed ( via close button or a commit. ).

There wouldn't be a backport to 1.7.X so you will need to
make use of the docker image built off master.

Regardless, this issue will still be opened pending a PR for the API.

@adelowo commented on GitHub (Feb 5, 2019): @ekrgb #4327 has been merged so the root cause of this issue should be fixed. The Stopwatch will be stopped whenever an issue is closed ( via ___close button___ or a commit. ). There wouldn't be a backport to `1.7.X` so you will need to make use of the docker image built off `master`. Regardless, this issue will still be opened pending a PR for the API.

GiteaMirror commented

2025-11-02 04:51:34 -06:00

@ekrgb commented on GitHub (Feb 5, 2019):

@adelowo great! thank you very much!

@ekrgb commented on GitHub (Feb 5, 2019): @adelowo great! thank you very much!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#2854