robert/todo

Watch

Fork 0

Listenuebergreifende Uebersicht "Heute faellig / Ueberfaellig" #165

New issue

Closed

opened 2026-09-06 19:55:40 +02:00 by lena · 2 comments

lena commented

2026-09-06 19:55:40 +02:00

Collaborator

Story: Listenuebergreifende Uebersicht "Heute faellig / Ueberfaellig"

As a Mitglied mit Todos in mehreren Listen,
I want to an einer Stelle alles sehen, was heute faellig oder ueberfaellig ist, ueber alle meine Listen hinweg,
so that ich nicht jede Liste einzeln durchklicken muss, um faellige Aufgaben zu finden.

Background

TodoItem.tsx zeigt bereits ein Faelligkeits-Badge (ueberfaellig/heute/zukuenftig) pro Zeile innerhalb einer einzelnen Liste, aber es gibt keine aggregierende Ansicht ueber mehrere Listen hinweg - man sieht faellige Aufgaben nur, wenn man zufaellig in der richtigen Liste ist.

Acceptance criteria:

Eine neue Ansicht (z. B. erreichbar ueber die Seitenleiste oder das Account-Menue) fasst alle Todos des aktuellen Nutzers ueber alle seine Todo-Listen (Standard und Priorisiert) zusammen, die heute faellig oder ueberfaellig sind.
Jeder Eintrag verlinkt zurueck in seine Quellliste.
Ein Leerzustand wird angezeigt, wenn nichts faellig/ueberfaellig ist.
Ein Todo aus dieser Ansicht abzuhaken wirkt sich genauso aus wie das Abhaken in der Quellliste (kein separater Zustand).

Out of scope for this story:

Einkaufsliste, Vorratsschrank, Masterpackliste (kein vergleichbares Faelligkeitsdatum-Konzept fuer Shopping/MasterPacking; Pantry-Zielmengen sind keine Datumsangaben).
Konfigurierbares Zeitfenster (z. B. "diese Woche faellig") - moegliche eigene Folge-Story.

Open questions: (escalate to human if unanswered)

Keine - Datenbasis (Faelligkeitsdatum, Ueberfaellig-Logik) existiert bereits pro Liste, hier geht es nur um die Aggregation.

## Story: Listenuebergreifende Uebersicht "Heute faellig / Ueberfaellig" **As a** Mitglied mit Todos in mehreren Listen, **I want to** an einer Stelle alles sehen, was heute faellig oder ueberfaellig ist, ueber alle meine Listen hinweg, **so that** ich nicht jede Liste einzeln durchklicken muss, um faellige Aufgaben zu finden. ## Background `TodoItem.tsx` zeigt bereits ein Faelligkeits-Badge (ueberfaellig/heute/zukuenftig) pro Zeile innerhalb einer einzelnen Liste, aber es gibt keine aggregierende Ansicht ueber mehrere Listen hinweg - man sieht faellige Aufgaben nur, wenn man zufaellig in der richtigen Liste ist. **Acceptance criteria:** - [ ] Eine neue Ansicht (z. B. erreichbar ueber die Seitenleiste oder das Account-Menue) fasst alle Todos des aktuellen Nutzers ueber alle seine Todo-Listen (Standard und Priorisiert) zusammen, die heute faellig oder ueberfaellig sind. - [ ] Jeder Eintrag verlinkt zurueck in seine Quellliste. - [ ] Ein Leerzustand wird angezeigt, wenn nichts faellig/ueberfaellig ist. - [ ] Ein Todo aus dieser Ansicht abzuhaken wirkt sich genauso aus wie das Abhaken in der Quellliste (kein separater Zustand). **Out of scope for this story:** - Einkaufsliste, Vorratsschrank, Masterpackliste (kein vergleichbares Faelligkeitsdatum-Konzept fuer Shopping/MasterPacking; Pantry-Zielmengen sind keine Datumsangaben). - Konfigurierbares Zeitfenster (z. B. "diese Woche faellig") - moegliche eigene Folge-Story. **Open questions:** (escalate to human if unanswered) - Keine - Datenbasis (Faelligkeitsdatum, Ueberfaellig-Logik) existiert bereits pro Liste, hier geht es nur um die Aggregation.

lena added the

priority/could

type/feature

labels

2026-09-06 19:55:40 +02:00

lena self-assigned this

2026-09-06 20:53:50 +02:00

lena added the

status/claimed

label

2026-09-06 20:53:51 +02:00

lena commented

2026-09-06 20:54:04 +02:00

Author

Collaborator

Claiming this. Plan: a new GetDueOrOverdueTodosForCurrentUserQuery that reuses the existing per-todo due-date logic (reads across every Standard/Priority todo list the current user is a member of, filtered to DoneDate == null && DueDate != null && DueDate <= today in the user's own local date, same shape SendDailyDigestEmailsCommandHandler's own due/overdue query already uses). Each result carries its TodoListId/Nr/Title/DueDate/TodoListTitle so the frontend can link back to the source list and reuse the existing CheckTodoCommand/UncheckTodoCommand toggle in place, no separate completion state. New frontend route/view (sidebar or account-menu entry, per the AC's own "z. B.") lists these across lists with an empty-state message. No open questions on the issue itself, so proceeding directly to design + implementation.

Claiming this. Plan: a new `GetDueOrOverdueTodosForCurrentUserQuery` that reuses the existing per-todo due-date logic (reads across every Standard/Priority todo list the current user is a member of, filtered to `DoneDate == null && DueDate != null && DueDate <= today` in the user's own local date, same shape `SendDailyDigestEmailsCommandHandler`'s own due/overdue query already uses). Each result carries its `TodoListId`/`Nr`/`Title`/`DueDate`/`TodoListTitle` so the frontend can link back to the source list and reuse the existing `CheckTodoCommand`/`UncheckTodoCommand` toggle in place, no separate completion state. New frontend route/view (sidebar or account-menu entry, per the AC's own "z. B.") lists these across lists with an empty-state message. No open questions on the issue itself, so proceeding directly to design + implementation.

lena referenced this issue from a commit

2026-09-06 21:12:09 +02:00

feat(#165): add GetDueOrOverdueTodosForCurrentUserQuery for a cross-list due/overdue aggregation

lena referenced this issue from a commit

2026-09-06 21:12:09 +02:00

feat(#165): add a cross-list due today / overdue overview page

lena commented

2026-09-06 21:12:33 +02:00

Author

Collaborator

Implemented and merged in commits 3415e2e (backend) and 28abd430 (frontend) on master.

Scope: A new GetDueOrOverdueTodosForCurrentUserQuery aggregates every not-done todo with a due date today or in the past, across all of the current user's Standard and Priority todo lists, excluding archived lists (a list's own archived state already means "hidden from the default view", surfacing its overdue todos here would work against that - a deliberate scope decision, not in the original AC text). A new sidebar entry ("Due today / Overdue") links to a new /due page listing every result with its source-list name, a due/overdue badge, and a link back into the source list (reusing SearchModal's own highlightTodoNr navigation-state convention). Checking a todo off from this view calls the exact same CheckTodoCommand the source list's own checkbox uses - no separate completion state, per the AC.

Out of scope, as specified: Shopping/Pantry/MasterPacking (no comparable due-date concept); a configurable time window beyond today/overdue.

Tests: 6 new backend unit tests (overdue vs. due-today vs. future, no-due-date exclusion, done-todo exclusion, non-member exclusion, archived-list exclusion, source-list-name passthrough) - confirmed to reach the expected DockerUnavailableException in this sandbox. 9 new/updated frontend tests (empty state, item rendering + back-links, badge distinction, check-off + optimistic removal, check-off failure re-adds the item, the new sidebar link, and the /due route rendering without triggering the default-list redirect).

Verification: dotnet build clean; full frontend suite green (126 files/1182 tests, up from 1175); tsc -b/npm run build clean. A dedicated security-review pass confirmed the new query's membership-scoping is structurally identical to the already-shipped SearchTodosQueryHandler (same UserEntity.TodoLists navigation-property traversal, userId always server-derived, never client input) and that the check-off path is independently re-authorized by CheckTodoCommandHandler regardless of what the aggregation query returns (defense in depth) - no IDOR or other findings.

Closing as done.

Implemented and merged in commits 3415e2e (backend) and 28abd430 (frontend) on master. **Scope:** A new `GetDueOrOverdueTodosForCurrentUserQuery` aggregates every not-done todo with a due date today or in the past, across all of the current user's Standard and Priority todo lists, excluding archived lists (a list's own archived state already means "hidden from the default view", surfacing its overdue todos here would work against that - a deliberate scope decision, not in the original AC text). A new sidebar entry ("Due today / Overdue") links to a new `/due` page listing every result with its source-list name, a due/overdue badge, and a link back into the source list (reusing `SearchModal`'s own `highlightTodoNr` navigation-state convention). Checking a todo off from this view calls the exact same `CheckTodoCommand` the source list's own checkbox uses - no separate completion state, per the AC. **Out of scope, as specified:** Shopping/Pantry/MasterPacking (no comparable due-date concept); a configurable time window beyond today/overdue. **Tests:** 6 new backend unit tests (overdue vs. due-today vs. future, no-due-date exclusion, done-todo exclusion, non-member exclusion, archived-list exclusion, source-list-name passthrough) - confirmed to reach the expected `DockerUnavailableException` in this sandbox. 9 new/updated frontend tests (empty state, item rendering + back-links, badge distinction, check-off + optimistic removal, check-off failure re-adds the item, the new sidebar link, and the `/due` route rendering without triggering the default-list redirect). **Verification:** `dotnet build` clean; full frontend suite green (126 files/1182 tests, up from 1175); `tsc -b`/`npm run build` clean. A dedicated security-review pass confirmed the new query's membership-scoping is structurally identical to the already-shipped `SearchTodosQueryHandler` (same `UserEntity.TodoLists` navigation-property traversal, `userId` always server-derived, never client input) and that the check-off path is independently re-authorized by `CheckTodoCommandHandler` regardless of what the aggregation query returns (defense in depth) - no IDOR or other findings. Closing as done.

lena closed this issue

2026-09-06 21:12:42 +02:00

lena referenced this issue from a commit

2026-09-06 21:13:38 +02:00

docs: record #165 cycle notes (SearchTodosQueryHandler-mirrored aggregation, redirect-guard regression test)