DB time-tracking sessions cannot be corrected after recording
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Área
- database, full-stack
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
Nowfor 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
- Start time tracking on a task.
- Forget to stop it at the actual end of the work session.
- Stop it later and discover that the recorded duration is too long.
- 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.
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 29
- Forks
- 2
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de logseq/db-test
-
Web build on a phone: the fold arrow of an h1/h2 block lies on its bullet, so tapping the bullet folds instead of zooming inPosiblemente ocupada @tiensonqin la tomó hace 2 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 87/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
Page titles with `$$`, `$&`, `` $` `` or `$'` change when block refs are resolvedPosiblemente ocupada @RaphaelFakhri la tomó hace 19 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
`#Asset` label is not displayed on asset nodes when `Hide from Node` is disabledPosiblemente ocupada @tiensonqin la tomó hace 22 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Todos los issues de logseq/db-test
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
jasonacox/pypowerwall#472 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
surrealdb/surrealdb.py#439 ·
Los mantenedores suelen responder en 6 días
-
zq prints a raw SQL 'no such table: index_default' error when the index has no default indexAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
mattgodbolt/zindex#67 ·
Los mantenedores suelen responder en 1 día
-
Add: Hindi Hits LogoAbiertocheck:passed logos:add
Dificultad 1/5 Menos de una hora Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día