robert/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 3 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Listenübersicht — Vollbild-Bearbeitungsmodus für Reihenfolge + Gruppen-Überschriften #170

New issue
Closed
opened 2026-09-07 09:20:49 +02:00 by lena · 3 comments
lena commented 2026-09-07 09:20:49 +02:00
Collaborator
Copy link

Story: Listenübersicht — Vollbild-Bearbeitungsmodus für Reihenfolge + Gruppen-Überschriften

As a Nutzer mit mehreren Listen,
I want to die Reihenfolge meiner Listen und Gruppen-Überschriften nur in einem eigenen, dafür vorgesehenen Bearbeitungsmodus ändern können — nicht mehr direkt in der alltäglichen Listenübersicht,
so that die alltägliche Übersicht aufgeräumter ist (mehr Platz für die Listentitel) und ich zusätzlich meine Listen in benannte Gruppen sortieren kann.

Kontext (verifiziert im Code, Folge-Story zu #147/#149):

  • TodoListMenu.tsx erlaubt aktuell direktes Umsortieren per Drag & Drop in der normalen Sidebar-Listenübersicht (SortableListRow, ein per Hover eingeblendeter Grip-Handle, absolut positioniert über dem bestehenden linken Padding jeder Zeile) — Backend: ReorderUserListsCommand/UserListOrderEntity, eine flache, rein pro Nutzer gespeicherte Reihenfolge (ListType, ListId, SortOrder), keine Gruppen-/Abschnitts-Struktur.
  • "+ Add List" (t('todo.menu.addList')) sitzt aktuell als einzige Aktion oben in der Listenübersicht.
  • Die Listenübersicht selbst ist die von links reingeschobene Sidebar (schmale Drawer-Ansicht), kein eigener, den ganzen Bildschirm nutzender Screen.

Acceptance criteria:

  • Neben "+ Add List" erscheint ein neuer Button "+ Bearbeiten" / "+ Edit".
  • Dieser Button öffnet einen eigenen, den gesamten verfügbaren App-Bildschirm nutzenden Bearbeitungsmodus — auf allen Bildschirmbreiten einheitlich als Vollbild, kein separates Modal-Verhalten auf Desktop. Dort und nur dort lässt sich die Listenreihenfolge per Drag & Drop ändern.
  • Im selben Bearbeitungsmodus lassen sich neue, frei benennbare Überschriften anlegen, um Listen in Gruppen zu unterteilen (z. B. "Haushalt", "Arbeit") — die Position dieser Überschriften relativ zu den Listen ist Teil der Reihenfolge und ebenfalls per Drag & Drop änderbar.
  • Gruppen-Überschriften sind, wie die Reihenfolge selbst (#149), rein pro Nutzer — keine geteilte/kollaborative Sichtbarkeit über mehrere Mitglieder einer Liste hinweg.
  • Listen müssen keiner Überschrift zugeordnet sein — lose, nicht gruppierte Listen bleiben erlaubt und erscheinen weiterhin normal in der Übersicht.
  • Die reguläre, alltägliche Listenübersicht (Sidebar) zeigt die Gruppen-Überschriften weiterhin an (rein informativ, dort nicht interaktiv änderbar), respektiert aber die im Bearbeitungsmodus festgelegte Reihenfolge/Gruppierung.
  • Der bisher in der regulären Listenübersicht sichtbare Drag-Handle (Grip-Symbol) entfällt dort vollständig — Umsortieren ist ab dieser Story ausschließlich im neuen Bearbeitungsmodus möglich.
  • Der durch den Wegfall des Handles freigewordene linke Platz wird genutzt: Listeneinträge in der regulären Übersicht beginnen weiter links und zeigen entsprechend mehr Zeichen des Titels an, bevor abgeschnitten wird (direkte Fortsetzung von #147, das den Handle noch nicht mit einrechnen musste, da er erst mit #149 dazukam).
  • Neu angelegte Listen erscheinen weiterhin automatisch am Ende (wie in #149 festgelegt), außerhalb jeder Gruppe, falls keine explizit zugewiesen ist.

Out of scope for this story:

  • Kein Umbenennen/Löschen von Listen selbst im neuen Bearbeitungsmodus — nur Reihenfolge + Gruppen-Überschriften.
  • Geteilte/kollaborative Projekt-Strukturen — siehe Entscheidung unten zu #150.

Open questions: Keine mehr — siehe Entscheidung unten.

Entscheidung (2026-09-07, mit dem Menschen geklärt):

  • Gruppen-Überschriften bleiben rein pro Nutzer, keine geteilte Sichtbarkeit — konsistent mit #149s bestehender Design-Entscheidung.
  • Lose, nicht gruppierte Listen sind erlaubt.
  • Der Bearbeitungsmodus ist immer Vollbild, auch auf Desktop-Breiten — kein separates Modal-Verhalten.
  • #150 ("Listen zu Projekten gruppieren") wurde als durch diese Story abgedeckt geschlossen — es wird aktuell keine geteilte/kollaborative Projekt-Gruppierung benötigt.
## Story: Listenübersicht — Vollbild-Bearbeitungsmodus für Reihenfolge + Gruppen-Überschriften **As a** Nutzer mit mehreren Listen, **I want to** die Reihenfolge meiner Listen und Gruppen-Überschriften nur in einem eigenen, dafür vorgesehenen Bearbeitungsmodus ändern können — nicht mehr direkt in der alltäglichen Listenübersicht, **so that** die alltägliche Übersicht aufgeräumter ist (mehr Platz für die Listentitel) und ich zusätzlich meine Listen in benannte Gruppen sortieren kann. **Kontext (verifiziert im Code, Folge-Story zu #147/#149):** - `TodoListMenu.tsx` erlaubt aktuell direktes Umsortieren per Drag & Drop in der normalen Sidebar-Listenübersicht (`SortableListRow`, ein per Hover eingeblendeter Grip-Handle, absolut positioniert über dem bestehenden linken Padding jeder Zeile) — Backend: `ReorderUserListsCommand`/`UserListOrderEntity`, eine flache, rein pro Nutzer gespeicherte Reihenfolge (`ListType`, `ListId`, `SortOrder`), keine Gruppen-/Abschnitts-Struktur. - "+ Add List" (`t('todo.menu.addList')`) sitzt aktuell als einzige Aktion oben in der Listenübersicht. - Die Listenübersicht selbst ist die von links reingeschobene Sidebar (schmale Drawer-Ansicht), kein eigener, den ganzen Bildschirm nutzender Screen. **Acceptance criteria:** - [ ] Neben "+ Add List" erscheint ein neuer Button "+ Bearbeiten" / "+ Edit". - [ ] Dieser Button öffnet einen eigenen, den gesamten verfügbaren App-Bildschirm nutzenden Bearbeitungsmodus — auf allen Bildschirmbreiten einheitlich als Vollbild, kein separates Modal-Verhalten auf Desktop. Dort und nur dort lässt sich die Listenreihenfolge per Drag & Drop ändern. - [ ] Im selben Bearbeitungsmodus lassen sich neue, frei benennbare Überschriften anlegen, um Listen in Gruppen zu unterteilen (z. B. "Haushalt", "Arbeit") — die Position dieser Überschriften relativ zu den Listen ist Teil der Reihenfolge und ebenfalls per Drag & Drop änderbar. - [ ] Gruppen-Überschriften sind, wie die Reihenfolge selbst (#149), rein pro Nutzer — keine geteilte/kollaborative Sichtbarkeit über mehrere Mitglieder einer Liste hinweg. - [ ] Listen müssen keiner Überschrift zugeordnet sein — lose, nicht gruppierte Listen bleiben erlaubt und erscheinen weiterhin normal in der Übersicht. - [ ] Die reguläre, alltägliche Listenübersicht (Sidebar) zeigt die Gruppen-Überschriften weiterhin an (rein informativ, dort nicht interaktiv änderbar), respektiert aber die im Bearbeitungsmodus festgelegte Reihenfolge/Gruppierung. - [ ] Der bisher in der regulären Listenübersicht sichtbare Drag-Handle (Grip-Symbol) entfällt dort vollständig — Umsortieren ist ab dieser Story ausschließlich im neuen Bearbeitungsmodus möglich. - [ ] Der durch den Wegfall des Handles freigewordene linke Platz wird genutzt: Listeneinträge in der regulären Übersicht beginnen weiter links und zeigen entsprechend mehr Zeichen des Titels an, bevor abgeschnitten wird (direkte Fortsetzung von #147, das den Handle noch nicht mit einrechnen musste, da er erst mit #149 dazukam). - [ ] Neu angelegte Listen erscheinen weiterhin automatisch am Ende (wie in #149 festgelegt), außerhalb jeder Gruppe, falls keine explizit zugewiesen ist. **Out of scope for this story:** - Kein Umbenennen/Löschen von Listen selbst im neuen Bearbeitungsmodus — nur Reihenfolge + Gruppen-Überschriften. - Geteilte/kollaborative Projekt-Strukturen — siehe Entscheidung unten zu #150. **Open questions:** Keine mehr — siehe Entscheidung unten. **Entscheidung (2026-09-07, mit dem Menschen geklärt):** - Gruppen-Überschriften bleiben rein pro Nutzer, keine geteilte Sichtbarkeit — konsistent mit #149s bestehender Design-Entscheidung. - Lose, nicht gruppierte Listen sind erlaubt. - Der Bearbeitungsmodus ist immer Vollbild, auch auf Desktop-Breiten — kein separates Modal-Verhalten. - #150 ("Listen zu Projekten gruppieren") wurde als durch diese Story abgedeckt geschlossen — es wird aktuell keine geteilte/kollaborative Projekt-Gruppierung benötigt.
lena self-assigned this 2026-09-07 12:21:20 +02:00
lena commented 2026-09-07 12:21:30 +02:00
Author
Collaborator
Copy link

Claimed for this cycle. Starting: full-screen edit mode for list reorder + named group headings (backend: new group-heading entity/migration extending ReorderUserListsCommand/UserListOrderEntity; frontend: TodoListMenu rework with an Edit-mode screen, drag handle removed from the everyday sidebar).

Claimed for this cycle. Starting: full-screen edit mode for list reorder + named group headings (backend: new group-heading entity/migration extending ReorderUserListsCommand/UserListOrderEntity; frontend: TodoListMenu rework with an Edit-mode screen, drag handle removed from the everyday sidebar).
lena commented 2026-09-07 14:31:09 +02:00
Author
Collaborator
Copy link

Implemented and pushed to master (2 commits: backend 4ee367f, frontend a56e48a).

Scope delivered (matches all acceptance criteria):

  • New "+ Edit" button next to "+ Add List" opens a full-screen list-order edit mode (always full-screen, no separate modal behavior on desktop, per the story's decision) - the only place reordering, and creating/deleting group headings, now happens.
  • New headings can be created (freely-named, always appended at the end) and deleted (trash button) from that screen. Deleting a heading only removes the divider; lists positioned under it stay put, un-grouped or under whatever heading precedes them next.
  • Headings share the existing per-user UserListOrderEntity ordering sequence as a 5th pseudo-list type (ListType.GroupHeading) - a heading's position relative to lists falls out of the existing single-sequence design for free, since grouping is purely positional (no GroupId field on any list, no heading assignment required for a list).
  • The everyday sidebar is now read-only: a heading renders as a plain divider label (respecting the order set in edit mode), the drag handle is gone entirely, and list titles keep the full width #147 originally gave them.
  • New lists still auto-append at the end (unchanged from #149).

Backend: GroupHeadingEntity (new migration), CreateGroupHeadingCommand/DeleteGroupHeadingCommand/GetGroupHeadingsOfCurrentUserQuery, AuthorizeGroupHeadingOwnerAccessQueryHandler (ownership gate, mirrors AuthorizeApiKeyOwnerAccessQueryHandler's shape), and ReorderUserListsCommandHandler extended to validate submitted headings server-side against the user's own current set (5th composed query, run concurrently with the existing 4). 12 new backend tests, all passing (843/843 full suite green).

Frontend: new ListOrderEditScreen.tsx (rendered via a React portal into document.body - the sidebar's md:translate-x-0 transform would otherwise trap a nested position: fixed overlay inside its own narrow bounds; caught by manually testing in a browser, not by any automated test, since jsdom doesn't model CSS containing blocks). TodoListMenu.tsx simplified to drop all dnd-kit wiring. 8 new/updated frontend tests, all passing (1218/1218 full suite green). tsc -b and npm run build both clean.

Self-review + security-review skill: ran both as the /code-review substitute (see CLAUDE.md step 3) - no findings. Ownership checks verified: CreateGroupHeadingCommand sets UserId from the session, never from client input; DeleteGroupHeadingCommand is gated by the new owner-access authorize query; GetGroupHeadingsOfCurrentUserQuery and the reorder validation both scope strictly to the current user server-side.

Known limitation this cycle: Docker Desktop crashed mid-cycle (WSL2 backend stuck, unrelated to this change) after one successful manual browser verification pass through the feature - couldn't get a second rebuild+revisit in after the portal fix. The fix itself is a well-understood, standard CSS containing-block issue (not a guess), and everything is covered by the automated suites above; noting this transparently rather than claiming a rebuild that didn't happen.

Implemented and pushed to master (2 commits: backend `4ee367f`, frontend `a56e48a`). **Scope delivered (matches all acceptance criteria):** - New "+ Edit" button next to "+ Add List" opens a full-screen list-order edit mode (always full-screen, no separate modal behavior on desktop, per the story's decision) - the only place reordering, and creating/deleting group headings, now happens. - New headings can be created (freely-named, always appended at the end) and deleted (trash button) from that screen. Deleting a heading only removes the divider; lists positioned under it stay put, un-grouped or under whatever heading precedes them next. - Headings share the existing per-user `UserListOrderEntity` ordering sequence as a 5th pseudo-list type (`ListType.GroupHeading`) - a heading's position relative to lists falls out of the existing single-sequence design for free, since grouping is purely positional (no GroupId field on any list, no heading assignment required for a list). - The everyday sidebar is now read-only: a heading renders as a plain divider label (respecting the order set in edit mode), the drag handle is gone entirely, and list titles keep the full width #147 originally gave them. - New lists still auto-append at the end (unchanged from #149). **Backend:** `GroupHeadingEntity` (new migration), `CreateGroupHeadingCommand`/`DeleteGroupHeadingCommand`/`GetGroupHeadingsOfCurrentUserQuery`, `AuthorizeGroupHeadingOwnerAccessQueryHandler` (ownership gate, mirrors `AuthorizeApiKeyOwnerAccessQueryHandler`'s shape), and `ReorderUserListsCommandHandler` extended to validate submitted headings server-side against the user's own current set (5th composed query, run concurrently with the existing 4). 12 new backend tests, all passing (843/843 full suite green). **Frontend:** new `ListOrderEditScreen.tsx` (rendered via a React portal into `document.body` - the sidebar's `md:translate-x-0` transform would otherwise trap a nested `position: fixed` overlay inside its own narrow bounds; caught by manually testing in a browser, not by any automated test, since jsdom doesn't model CSS containing blocks). `TodoListMenu.tsx` simplified to drop all dnd-kit wiring. 8 new/updated frontend tests, all passing (1218/1218 full suite green). `tsc -b` and `npm run build` both clean. **Self-review + security-review skill:** ran both as the `/code-review` substitute (see `CLAUDE.md` step 3) - no findings. Ownership checks verified: `CreateGroupHeadingCommand` sets `UserId` from the session, never from client input; `DeleteGroupHeadingCommand` is gated by the new owner-access authorize query; `GetGroupHeadingsOfCurrentUserQuery` and the reorder validation both scope strictly to the current user server-side. **Known limitation this cycle:** Docker Desktop crashed mid-cycle (WSL2 backend stuck, unrelated to this change) after one successful manual browser verification pass through the feature - couldn't get a second rebuild+revisit in after the portal fix. The fix itself is a well-understood, standard CSS containing-block issue (not a guess), and everything is covered by the automated suites above; noting this transparently rather than claiming a rebuild that didn't happen.
lena closed this issue 2026-09-07 14:31:15 +02:00
lena commented 2026-09-07 15:21:14 +02:00
Author
Collaborator
Copy link

Follow-up: Docker Desktop recovered a few minutes after the closing comment above. Rebuilt the review container and fully re-verified live: logged in, opened "+ Edit" and confirmed the screen now genuinely covers the whole viewport (the portal fix works), created a test group heading (appeared at the end with a delete button), closed edit mode and confirmed the sidebar renders it as a plain read-only divider with no drag handle, then reopened edit mode and deleted the heading (the 3 lists were untouched). No remaining gaps.

Follow-up: Docker Desktop recovered a few minutes after the closing comment above. Rebuilt the review container and fully re-verified live: logged in, opened "+ Edit" and confirmed the screen now genuinely covers the whole viewport (the portal fix works), created a test group heading (appeared at the end with a delete button), closed edit mode and confirmed the sidebar renders it as a plain read-only divider with no drag handle, then reopened edit mode and deleted the heading (the 3 lists were untouched). No remaining gaps.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/in-app-notifications
feature/list-archiving
feature/filter-search
No results found.
Labels
Clear labels   
priority/could

   
priority/must

   
priority/should

   
priority/wont

   
status/blocked

   
status/claimed

   
status/done-migrated

   
type/bug

   
type/feature

   
type/infra

   
type/tech-debt
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
lena
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
robert/todo#170
No description provided.