DB query tables omit per-task and aggregate tracked time
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- frontend
Hướng nghiên cứu
The issue names no implementation files or tests; it identifies DB Query Table and List views, the query heading, and existing status-history duration calculation as starting points. Read the query display and aggregation implementation, then trace how task duration is calculated. Done means each result can show Time Spent, the heading totals the complete matching result set, and values update as described; focused worker and UI tests are expected.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Related issue
This follows up on #465, which reported that DB query results did not expose time-tracking data for individual task rows. That issue was closed as stale, but the limitation is still present in the current DB version.
What happened?
In a DB graph, a query that returns tasks with recorded time behaves differently depending on the selected view:
- List View shows the tracked duration on each rendered task.
- Table View has no
Time Spentcolumn and does not show the duration for individual task rows. - The
Live Query (N)heading does not show the aggregate tracked time for the complete result set.
This is also a regression relative to Logseq OG/file graphs. OG query tables expose the aggregate tracked time, even though #465 documents that their individual rows do not expose each task's duration. The DB version currently provides neither value in Table View, so users lose the invoice total they could obtain in OG.
Here, "Table View" means the table view of a Query block inside a DB graph, not the global graph visualization.
OG Table (narrow and scrolled to the left to show upper left hand corner with aggregate)
DB Table (no aggregate data shown)
Reproduction
- In a DB graph, create several tasks under a shared tag or parent reference.
- Move each task through
Doinglong enough to record time, then complete the tasks. - Create a query that returns those tasks.
- Switch the query to Table View.
- Open the column visibility menu and inspect the query heading.
Observed:
- No per-row
Time Spentcolumn is available. - No aggregate duration is shown beside
Live Query (N)or elsewhere in the query view. - Switching to List View shows the individual task duration, confirming that the underlying time data is available.
Expected behavior
- Query Table View provides a
Time Spentcolumn for each task result. - The query heading shows the aggregate tracked time for all results represented by
Live Query (N). - The aggregate uses the complete matching result set, not only the currently rendered/virtualized rows.
- The aggregate remains available when switching between Table and List views.
- Values refresh when query membership, view filters, or relevant task status history changes.
Sorting or filtering by the calculated duration is not required to address this issue.
Why this matters
A common workflow is to query completed tasks for an invoice period and use their aggregate tracked time to prepare an invoice. Without an aggregate, the DB version cannot replace the equivalent OG workflow. This is a migration blocker for users who rely on Logseq for task-based time tracking and invoicing.
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 query display/aggregation, reuse the existing status-history duration calculation, and include focused worker and UI tests.
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 29
- Fork
- 2
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của logseq/db-test
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
-
Page titles with `$$`, `$&`, `` $` `` or `$'` change when block refs are resolvedCó thể đã có người làm @RaphaelFakhri đã nhận 20 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
`#Asset` label is not displayed on asset nodes when `Hide from Node` is disabledCó thể đã có người làm @tiensonqin đã nhận 23 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Tất cả issue của logseq/db-test
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
quarto-dev/q2#1155 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
backlog priority: low ui
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
storytold/vectorcraft#6445 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
awslabs/visual-asset-management-system#1278 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
VoteIT/voteit_frontend#446 ·