DB time-tracking sessions cannot be corrected after recording

オープン
  • 何か問題がありますか？
#1,471 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
領域
database, full-stack

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
言語のデータがありません
スター
29
フォーク
2
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

logseq/db-test のほかの issue

logseq/db-test の issue をすべて見る

似ている issue

Databases の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。