Add labels for worktime type in time tracker #14931

New Issue

GiteaMirror · 2025-11-02T11:26:06-06:00

GiteaMirror commented

2025-11-02 11:26:06 -06:00

Originally created by @christophmatt1 on GitHub (Sep 6, 2025).

Feature Description

Currently, the time tracker in Gitea only records the duration of tracked work, but it does not provide a way to categorize or label the type of worktime (e.g. development, review, meeting, documentation).

I would like to propose adding a feature that allows labeling of time entries. This would make reporting and analytics much more meaningful.

Possible Implementation

From a database perspective, there are two possible approaches:

Add a new table (e.g. time_tracker_label)
- Stores label definitions for different types of worktime.
- tracked_time entries would then reference this table via a foreign key.
Extend the existing label table with an additional type enum
- Define a new enum for label type (e.g. issue, pull_request, time_entry).
- tracked_time entries would then be linked with the appropriate label via a new relation.

Screenshots

No response

Originally created by @christophmatt1 on GitHub (Sep 6, 2025). ### Feature Description Currently, the time tracker in Gitea only records the duration of tracked work, but it does not provide a way to categorize or label the *type* of worktime (e.g. development, review, meeting, documentation). I would like to propose adding a feature that allows labeling of time entries. This would make reporting and analytics much more meaningful. ### Possible Implementation From a database perspective, there are two possible approaches: 1. **Add a new table** (e.g. `time_tracker_label`) * Stores label definitions for different types of worktime. * `tracked_time` entries would then reference this table via a foreign key. 2. **Extend the existing `label` table** with an additional `type` enum * Define a new enum for label type (e.g. `issue`, `pull_request`, `time_entry`). * `tracked_time` entries would then be linked with the appropriate label via a new relation. ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 11:26:06 -06:00

GiteaMirror commented

2025-11-02 11:26:07 -06:00

@lafriks commented on GitHub (Sep 6, 2025):

I don't think the new table is needed as only a single label could be added to specific time entry so need to add a new column to the tracked_time table that would reference label

@lafriks commented on GitHub (Sep 6, 2025): I don't think the new table is needed as only a single label could be added to specific time entry so need to add a new column to the tracked_time table that would reference label

GiteaMirror commented

2025-11-02 11:26:07 -06:00

@lafriks commented on GitHub (Sep 6, 2025):

Also I don't think a issue/pull_request needs separate label definitions

@lafriks commented on GitHub (Sep 6, 2025): Also I don't think a issue/pull_request needs separate label definitions

GiteaMirror commented

2025-11-02 11:26:07 -06:00

@christophmatt1 commented on GitHub (Sep 7, 2025):

It might make sense to have a predefined set of categories that can be managed at different levels:

Repository level: project-specific categories
Organization level: shared categories across all repositories in an org
Global level: instance-wide defaults available everywhere
Combined view: when logging time, the user would see all available categories from Repo + Org + Global scope.

When tracking time, users could then select one or multiple categories (1-n) from this predefined set.
This would keep reporting consistent while still allowing project-specific flexibility.

@christophmatt1 commented on GitHub (Sep 7, 2025): It might make sense to have a **predefined set of categories** that can be managed at different levels: * **Repository level**: project-specific categories * **Organization level**: shared categories across all repositories in an org * **Global level**: instance-wide defaults available everywhere * **Combined view**: when logging time, the user would see all available categories from Repo + Org + Global scope. When tracking time, users could then **select one or multiple categories (1-n)** from this predefined set. This would keep reporting consistent while still allowing project-specific flexibility.

GiteaMirror commented

2025-11-02 11:26:07 -06:00

@christophmatt1 commented on GitHub (Sep 7, 2025):

I don't think the new table is needed as only a single label could be added to specific time entry so need to add a new column to the tracked_time table that would reference label

Defining labels only once globally or reducing it to a single column would remove the flexibility many users need.
That would make it little more than a text field.
With a separate relation table, labels can be scoped (Repo/Org/Global), reused, and combined (1-n), so both simple and more flexible use cases are supported.

@christophmatt1 commented on GitHub (Sep 7, 2025): > I don't think the new table is needed as only a single label could be added to specific time entry so need to add a new column to the tracked_time table that would reference label Defining labels only once globally or reducing it to a single column would remove the flexibility many users need. That would make it little more than a text field. With a separate relation table, labels can be scoped (Repo/Org/Global), reused, and combined (1-n), so both simple and more flexible use cases are supported.

GiteaMirror commented

2025-11-02 11:26:08 -06:00

@vsysoev commented on GitHub (Sep 9, 2025):

May be comment will be better for tracking time. For ex:
2h review #<num> and short summary of work.

@vsysoev commented on GitHub (Sep 9, 2025): May be comment will be better for tracking time. For ex: 2h review `#<num>` and short summary of work.

GiteaMirror commented

2025-11-02 11:26:08 -06:00

@christophmatt1 commented on GitHub (Sep 9, 2025):

May be comment will be better for tracking time. For ex: 2h review #<num> and short summary of work.

Yes, if I was mainly looking for a worklog, comments would be fine. But what I actually need is proper reporting and the ability to transfer the tracked time into an invoice. Right now I still do this manually, but with a simple label it could be automated. I’ve built myself a workaround with comments, but of course that only works as well as you manage to keep the format consistent.

@christophmatt1 commented on GitHub (Sep 9, 2025): > May be comment will be better for tracking time. For ex: 2h review `#<num>` and short summary of work. Yes, if I was mainly looking for a worklog, comments would be fine. But what I actually need is proper reporting and the ability to transfer the tracked time into an invoice. Right now I still do this manually, but with a simple label it could be automated. I’ve built myself a workaround with comments, but of course that only works as well as you manage to keep the format consistent.

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#14931