Sidebar — Standard-Icon für Einkaufsliste/Vorratsschrank/Masterpackliste, solange nicht individuell angepasst #188

Closed
opened 2026-09-12 00:02:15 +02:00 by lena · 2 comments
Collaborator

Story: Sidebar — Standard-Icon für Einkaufsliste/Vorratsschrank/Masterpackliste, solange nicht individuell angepasst

As a Nutzer der App,
I want to dass jede Liste in der Übersicht standardmäßig ein zum Listentyp passendes Icon zeigt, auch ohne dass ich sie manuell anpasse,
so that ich die Listentypen auf einen Blick unterscheiden kann, genau wie bei To-Do-Listen.

Kontext (verifiziert im Code, inkl. eines Live-Tests im lokalen Review-Container):

  • #181 hat "Erscheinungsbild anpassen" (Farbe/Icon) bereits für alle 4 Listentypen implementiert und funktioniert nachweislich (live getestet: Einkaufsliste "Wocheneinkauf" ließ sich per Menü → "Customise" erfolgreich auf ein Warenkorb-Icon + Farbe umstellen, die Sidebar aktualisierte sich sofort korrekt).
  • Das eigentliche Problem liegt woanders: TodoListItem.tsx rendert IMMER ein Icon (Standardwert 'List'), während ShoppingListItem.tsx/PantryItem.tsx/MasterPackingListItem.tsx ein isCustomised-Gate haben (color !== 'Grey' || icon !== 'List') - solange eine Liste NICHT individuell angepasst wurde, wird dort gar kein Icon gerendert (eine bewusste #181-Entscheidung, um das Aussehen bereits bestehender Listen beim damaligen Feature-Rollout nicht zu verändern).
  • Ergebnis: neu angelegte wie auch nie angepasste Einkaufslisten/Vorratsschränke/Masterpacklisten zeigen dauerhaft KEIN Icon, bis der Nutzer manuell "Customise" öffnet - im Gegensatz zu To-Do-Listen, die immer ein Icon zeigen.

Acceptance criteria:

  • Jeder der 4 Listentypen zeigt ein zum Typ passendes Standard-Icon, auch wenn die Liste nie individuell angepasst wurde (z. B. Warenkorb für Einkaufsliste, ein Schrank-/Kisten-Icon für Vorratsschrank, ein Koffer-/Rucksack-Icon für Masterpackliste - vorhandene Icon-Auswahl aus ListAppearanceDialog.tsx verwenden, kein neues Icon-Set nötig).
  • Das Icon einer bereits individuell angepassten Liste bleibt unverändert (keine Regression für #181).
  • Bereits bestehende, nie angepasste Listen (Farbe=Grey, Icon=List in der DB) zeigen nach dem Deploy automatisch das neue typspezifische Standard-Icon, ohne dass der Nutzer aktiv etwas tun muss.

Out of scope:

  • Die Farb-Logik bleibt unverändert (weiterhin neutral, bis der Nutzer eine Farbe wählt).
## Story: Sidebar — Standard-Icon für Einkaufsliste/Vorratsschrank/Masterpackliste, solange nicht individuell angepasst **As a** Nutzer der App, **I want to** dass jede Liste in der Übersicht standardmäßig ein zum Listentyp passendes Icon zeigt, auch ohne dass ich sie manuell anpasse, **so that** ich die Listentypen auf einen Blick unterscheiden kann, genau wie bei To-Do-Listen. **Kontext (verifiziert im Code, inkl. eines Live-Tests im lokalen Review-Container):** - #181 hat "Erscheinungsbild anpassen" (Farbe/Icon) bereits für alle 4 Listentypen implementiert und funktioniert nachweislich (live getestet: Einkaufsliste "Wocheneinkauf" ließ sich per Menü → "Customise" erfolgreich auf ein Warenkorb-Icon + Farbe umstellen, die Sidebar aktualisierte sich sofort korrekt). - Das eigentliche Problem liegt woanders: `TodoListItem.tsx` rendert IMMER ein Icon (Standardwert `'List'`), während `ShoppingListItem.tsx`/`PantryItem.tsx`/`MasterPackingListItem.tsx` ein `isCustomised`-Gate haben (`color !== 'Grey' || icon !== 'List'`) - solange eine Liste NICHT individuell angepasst wurde, wird dort gar kein Icon gerendert (eine bewusste #181-Entscheidung, um das Aussehen bereits bestehender Listen beim damaligen Feature-Rollout nicht zu verändern). - Ergebnis: neu angelegte wie auch nie angepasste Einkaufslisten/Vorratsschränke/Masterpacklisten zeigen dauerhaft KEIN Icon, bis der Nutzer manuell "Customise" öffnet - im Gegensatz zu To-Do-Listen, die immer ein Icon zeigen. **Acceptance criteria:** - [ ] Jeder der 4 Listentypen zeigt ein zum Typ passendes Standard-Icon, auch wenn die Liste nie individuell angepasst wurde (z. B. Warenkorb für Einkaufsliste, ein Schrank-/Kisten-Icon für Vorratsschrank, ein Koffer-/Rucksack-Icon für Masterpackliste - vorhandene Icon-Auswahl aus `ListAppearanceDialog.tsx` verwenden, kein neues Icon-Set nötig). - [ ] Das Icon einer bereits individuell angepassten Liste bleibt unverändert (keine Regression für #181). - [ ] Bereits bestehende, nie angepasste Listen (Farbe=Grey, Icon=List in der DB) zeigen nach dem Deploy automatisch das neue typspezifische Standard-Icon, ohne dass der Nutzer aktiv etwas tun muss. **Out of scope:** - Die Farb-Logik bleibt unverändert (weiterhin neutral, bis der Nutzer eine Farbe wählt).
lena self-assigned this 2026-09-29 19:26:09 +02:00
Author
Collaborator

Claimed (go-Lauf 2026-09-29). Plan: typspezifisches Standard-Icon rein im Frontend als Anzeige-Fallback, wenn das gespeicherte Icon noch der Default List ist - keine Datenmigration, angepasste Listen bleiben unveraendert. Danach folgt #189.

Claimed (go-Lauf 2026-09-29). Plan: typspezifisches Standard-Icon rein im Frontend als Anzeige-Fallback, wenn das gespeicherte Icon noch der Default `List` ist - keine Datenmigration, angepasste Listen bleiben unveraendert. Danach folgt #189.
Author
Collaborator

Erledigt in 2974edd6.

Umfang: Nie angepasste Einkaufslisten, Vorratsschraenke und Masterpacklisten zeigen jetzt ein typspezifisches Standard-Icon in der Sidebar (Einkaufsliste: Warenkorb, Vorratsschrank: Haus, Masterpackliste: Aktenkoffer - ersetzt das bisherige Koffer-Emoji). Gleiche Regel im Listen-Reihenfolge-Bearbeiten-Bildschirm.

Entscheidungen:

  • Reiner Anzeige-Fallback im Frontend (effectiveListIcon in lib/listIcons.ts): gespeichertes Icon List wird je Typ auf das Standard-Icon abgebildet. Keine Datenmigration noetig, bestehende Listen bekommen das Icon sofort; explizit gewaehlte Icons bleiben unveraendert.
  • Farbe bleibt neutral (Icon erbt die Textfarbe der Zeile), bis der Nutzer eine Farbe waehlt.
  • Der Anpassen-Dialog markiert das tatsaechlich angezeigte Icon vor.
  • Bekannte Einschraenkung: wer fuer eine Einkaufsliste/Vorratsschrank/Masterpackliste explizit das generische Listen-Icon waehlt, sieht weiterhin das Typ-Icon, weil List der Nicht-angepasst-Marker ist.
  • Vorratsschrank-Icon: aus der bestehenden Auswahl gibt es kein Schrank-/Kisten-Icon; Haus war die naechstliegende Wahl ohne Erweiterung des Icon-Enums.

Tests: neue Unit-Tests fuer effectiveListIcon, angepasste Komponenten-Tests fuer Shopping/Pantry/MasterPacking (Standard-Icon sichtbar, ungefaerbt); volle Frontend-Suite 1506/1506 gruen, Build gruen.

Erledigt in 2974edd6. **Umfang:** Nie angepasste Einkaufslisten, Vorratsschraenke und Masterpacklisten zeigen jetzt ein typspezifisches Standard-Icon in der Sidebar (Einkaufsliste: Warenkorb, Vorratsschrank: Haus, Masterpackliste: Aktenkoffer - ersetzt das bisherige Koffer-Emoji). Gleiche Regel im Listen-Reihenfolge-Bearbeiten-Bildschirm. **Entscheidungen:** - Reiner Anzeige-Fallback im Frontend (`effectiveListIcon` in `lib/listIcons.ts`): gespeichertes Icon `List` wird je Typ auf das Standard-Icon abgebildet. Keine Datenmigration noetig, bestehende Listen bekommen das Icon sofort; explizit gewaehlte Icons bleiben unveraendert. - Farbe bleibt neutral (Icon erbt die Textfarbe der Zeile), bis der Nutzer eine Farbe waehlt. - Der Anpassen-Dialog markiert das tatsaechlich angezeigte Icon vor. - Bekannte Einschraenkung: wer fuer eine Einkaufsliste/Vorratsschrank/Masterpackliste explizit das generische Listen-Icon waehlt, sieht weiterhin das Typ-Icon, weil `List` der Nicht-angepasst-Marker ist. - Vorratsschrank-Icon: aus der bestehenden Auswahl gibt es kein Schrank-/Kisten-Icon; Haus war die naechstliegende Wahl ohne Erweiterung des Icon-Enums. **Tests:** neue Unit-Tests fuer `effectiveListIcon`, angepasste Komponenten-Tests fuer Shopping/Pantry/MasterPacking (Standard-Icon sichtbar, ungefaerbt); volle Frontend-Suite 1506/1506 gruen, Build gruen.
lena 2026-09-29 19:37:21 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
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#188
No description provided.