DB time-tracking sessions cannot be corrected after recording

Open
#1,471 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active

Research direction

Read the current time-tracking UI and the worker code that stores status-history entries, then inspect focused worker and UI tests. Implement a session editor that changes the selected start or end boundary, validates chronology, and refreshes task, query-row, and aggregate durations; done when completed and active sessions follow the stated edit rules and the results update immediately.

Written by the indexing model from the issue text.

Description

Summary

Logseq OG gave users an escape hatch for correcting inaccurate time tracking: because clock data lived in the page's Markdown, a user could edit the underlying timestamps when a task was started or stopped at the wrong time.

That kind of "fix up" is no longer possible in the DB version. The status-history data used to calculate tracked time is not directly editable, and the current time-tracking UI is read-only. Once a session boundary is wrong, there is no supported way to correct it.

Proposed feature

Make a task's tracked-time value interactive and provide a focused editor for its recorded time sessions.

For each derived session, show:

  • start date and time
  • end date and time (or Now for an active session)
  • calculated duration
  • an Edit action

A completed session should allow its start and end time to be changed. An active session should allow its start time to be changed while keeping its live Now endpoint read-only. Saving should validate that session boundaries remain chronologically valid and should update only the selected time-history entries.

After a successful edit, the task's duration—and any query row or aggregate displaying it—should update immediately.

This should be a purpose-built time-session editor rather than exposing arbitrary database/history mutation. It does not need to add, delete, split, or merge sessions in its first iteration.

Example use case

  1. Start time tracking on a task.
  2. Forget to stop it at the actual end of the work session.
  3. Stop it later and discover that the recorded duration is too long.
  4. Click the task's tracked time, edit the session's end timestamp to the actual stopping time, and save.

Why this matters

I use Logseq as my primary time-tracking tool, including for work that I invoice. Mistakes such as starting late, stopping late, or forgetting to change a task's status are inevitable, so the ability to correct recorded times is essential.

In Logseq OG I could recover by editing the Markdown. The DB version removes that workaround without providing a supported replacement. I cannot migrate my working graph to the DB version without a way to correct time-tracking sessions.

This is related to #1470, which covers showing per-task and aggregate tracked time in query results, but it is independently useful and could be implemented as a separate PR.

Environment

Reproduced in the current local DB development build on macOS (Logseq Desktop 2.0.2).

PR willingness
  • I am willing to submit a focused PR adding the per-task query column and aggregate query time.

I have already investigated the current implementation and would keep the change scoped to start/stop time editing, with focused worker and UI tests.

Dominant language
No language data
Stars
29
Forks
2
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from logseq/db-test

All issues in logseq/db-test

Similar issues

More Databases issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.