Automatically stop tracking time on one issue if I start tracking time on another #4967

New Issue

GiteaMirror · 2025-11-02T06:09:26-06:00

GiteaMirror commented

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

Originally created by @bobemoe on GitHub (Feb 28, 2020).

Currently if I'm already tracking time on an issue and view a different issue there is a notice saying that I am already tracking time and links to the issue I am tracking on. Good :)

It doesn't prevent me starting to track time on a second issue though. At this point the "already tracking time" message disappears (confusing) if I'm viewing one of the two issues I'm tracking time on.

If I view another issue, there is the "already tracking time" message but it only links to one of the two issue. (confusing - I never know I'm accidentally tracking two issues until I stop tracking on one and the notice remains). Personally I cant see a need to track time on two issues at once - is this a bug??

Maybe needs a config option if multiple tracking is deemed a required feature. Perhaps even 3 options Multiple Tracking: Prevent|Stop Other|Allow

Originally created by @bobemoe on GitHub (Feb 28, 2020). Currently if I'm already tracking time on an issue and view a different issue there is a notice saying that I am already tracking time and links to the issue I am tracking on. Good :) It doesn't prevent me starting to track time on a second issue though. At this point the "already tracking time" message disappears (confusing) if I'm viewing one of the two issues I'm tracking time on. If I view another issue, there is the "already tracking time" message but it only links to one of the two issue. (confusing - I never know I'm accidentally tracking two issues until I stop tracking on one and the notice remains). Personally I cant see a need to track time on two issues at once - is this a bug?? Maybe needs a config option if multiple tracking is deemed a required feature. Perhaps even 3 options `Multiple Tracking: Prevent|Stop Other|Allow`

GiteaMirror added the issue/confirmed type/enhancement type/bug labels 2025-11-02 06:09:26 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

2025-11-02 06:09:27 -06:00

@guillep2k commented on GitHub (Feb 28, 2020):

I can see both use cases. I agree a setting to select one of the two forms would be required if the behavior is changed. There's however the question, does the time compute twice?

I'm labeling this also kind/bug because of the confusing UI feedback.

@guillep2k commented on GitHub (Feb 28, 2020): I can see both use cases. I agree a setting to select one of the two forms would be required if the behavior is changed. There's however the question, does the time compute twice? I'm labeling this also `kind/bug` because of the confusing UI feedback.

GiteaMirror commented

2025-11-02 06:09:27 -06:00

@bobemoe commented on GitHub (Feb 28, 2020):

I split the only slightly related other idea into separate issue: #10539

@bobemoe commented on GitHub (Feb 28, 2020): I split the only slightly related other idea into separate issue: #10539

GiteaMirror commented

2025-11-02 06:09:27 -06:00

@bobemoe commented on GitHub (Feb 28, 2020):

As for your question, currently the time does compute twice, if I start tracking on two issues, and stop tracking 10 mins later on both issues, the I have clocked a total of 20 mins in a 10 min timespan! I can't really see a use case for that?

I'm not sure how else it could be handled without stopping (or pause/resume - complicated!?) the other issue?

@bobemoe commented on GitHub (Feb 28, 2020): As for your question, currently the time does compute twice, if I start tracking on two issues, and stop tracking 10 mins later on both issues, the I have clocked a total of 20 mins in a 10 min timespan! I can't really see a use case for that? I'm not sure how else it could be handled without stopping (or pause/resume - complicated!?) the other issue?

GiteaMirror commented

2025-11-02 06:09:28 -06:00

@guillep2k commented on GitHub (Feb 29, 2020):

@bobemoe Conceptually it's possible that two issues are so related that when you work in a PR to fix one you're also working to fixing the other. IMHO, however, handling such a complex schedule is out of the scope of Gitea. So I'd say we should pause the old issue when a new issue is started working on. I'd show a warning dialog before submitting, though.

@guillep2k commented on GitHub (Feb 29, 2020): @bobemoe Conceptually it's possible that two issues are so related that when you work in a PR to fix one you're also working to fixing the other. IMHO, however, handling such a complex schedule is out of the scope of Gitea. So I'd say we should pause the old issue when a new issue is started working on. I'd show a warning dialog before submitting, though.

GiteaMirror commented

2025-11-02 06:09:28 -06:00

@stale[bot] commented on GitHub (Apr 29, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 29, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror referenced this issue

2025-11-02 14:08:30 -06:00

[PR #4967] [MERGED] ADD: Hint to function of docker version tags in tutorial #17571

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