Listen-Erscheinungsbild (Farbe/Symbol) auch fuer Einkaufsliste, Vorratsschrank und Masterpackliste #181
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
robert/todo#181
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Story: Listen-Erscheinungsbild (Farbe/Symbol) auch fuer Einkaufsliste, Vorratsschrank und Masterpackliste
As a Nutzer mit mehreren Listen desselben Typs (z. B. mehrere Masterpacklisten fuer "Camping" und "Geschaeftsreise", oder mehrere Einkaufslisten),
I want to jeder Liste eine eigene Farbe und ein eigenes Symbol geben koennen,
so that ich sie in der Seitenleiste auf einen Blick unterscheiden kann, so wie ich das bei meinen To-Do-Listen bereits kann.
Kontext (verifiziert im Code): ListAppearanceDialog.tsx und die TODO_LIST_COLORS/TODO_LIST_ICONS-Auswahl existieren bereits, sind aber nur in ListActionsMenu.tsx (Todo-spezifisch) eingehaengt. ShoppingListItem.tsx hat laut eigenem Code-Kommentar bewusst nur einen fixen Akzent-Punkt ("Shopping Lists have no per-list color to reuse a swatch from"). MasterPackingListItem.tsx rendert ein hartkodiertes ??-Emoji ohne Auswahlmoeglichkeit. Seit #150 (Listen-Gruppierung) und der Moeglichkeit mehrerer Masterpacklisten ist optische Unterscheidbarkeit relevanter geworden als beim urspruenglichen Einzellisten-Design.
Acceptance criteria:
Out of scope for this story:
Open questions: (escalate to human if unanswered)
Claiming this for the current autonomous cycle. Plan: mirror the existing Todo-list appearance feature (
SetTodoListAppearanceCommandHandler.cs,TodoListColor/TodoListIconcolumns withGrey/Listsentinel defaults,ListAppearanceDialog.tsx) onto Shopping/Pantry/MasterPackingList: one migration per entity adding the same two enum columns with the same fixed-appearance-equivalent sentinel default, one SetXAppearanceCommand per list type, a new menu entry in each list menu reusing the existing dialog/picker, and sidebar rendering swapped from the current fixed accent-dot/hardcoded emoji to the stored color/icon. No visual change for any existing list until a user actively picks an appearance, per the AC.Done. Implemented in
849f398b(backend) +b421bd82(frontend).Scope: Einkaufsliste, Vorratsschrank and Masterpackliste each now have an "Erscheinungsbild anpassen" (Customise) entry in their list menu, reusing the same color/icon picker Todo lists already had (#23). Backend: one Color/Icon column pair per entity (3 separate migrations), one SetXAppearanceCommand per list type - owner-only, Shopping broadcasts live via WS like Rename/Archive already do, Pantry/MasterPacking refetch on save since neither has a WS channel. Duplicating a list now carries its source's appearance over, matching the existing Todo-list precedent.
No existing list changes appearance on its own: the sidebar only switches from the old fixed accent-dot/hardcoded emoji to the coloured dot+icon+text once a list is genuinely customised (color/icon != the Grey/List default) - verified live in the local review container by creating a fresh list (unchanged look), then customising it (color/icon apply and persist across a reload).
Along the way, found and fixed 3 more pre-existing handlers (Accept invitation, Leave, Remove member) that were still broadcasting a defaulted
IsArchived: falseinstead of the list's real archived state - the same gap #162 fixed for Rename/Archive/Unarchive, just never swept across every construction site ofShoppingListBroadcastDto. Fixed alongside the new Color/Icon fields so joining/leaving/removing a member from an archived or customised list no longer resets it for everyone else's view.Tests: 6 new backend handler tests (2 per list type), ~15 new/updated frontend tests across the 3 item components + the generalized
ListAppearanceDialog, plus fixture updates in ~20 pre-existing test files for the new required DTO fields. Backend suite genuinely green against real Postgres this cycle (914+52+119, Docker was available for once) - not the usual Docker-masked local run. Frontend: 134 files / 1295 tests green. Self-review + security-review skill: no findings (mirrors an already-reviewed pattern, owner-only auth throughout, no new input surface beyond two closed enums). Local review container rebuilt and health-checked; live-verified the feature end-to-end in a browser for both the WS-broadcast path (Shopping) and the refetch path (Pantry).