Bug - Bestehende Listen erhalten neu entwickelte Features nicht (vollstaendig) #213

Closed
opened 2026-09-28 08:51:16 +02:00 by lena · 2 comments
Collaborator

Bug: Bestehende Listen bekommen neue Features nicht bzw. nicht immer

Beobachtung (Mensch, Live-Umgebung): Wenn ein Listentyp (z. B. Einkaufsliste oder normale To-Do-Liste) um neue Features erweitert wird, kommen diese bei bereits vorher angelegten Listen nicht oder nicht vollstaendig an. Neu angelegte Listen haben sie.

Erwartung: Jede Liste eines Typs hat immer den vollen Umfang aller fertig entwickelten Features dieses Typs - unabhaengig davon, wann sie angelegt wurde.

Vermutete Ursachen (zu verifizieren):

  • Features, die beim Anlegen einer Liste Daten seeden (z. B. Standard-Kategorien in CreateShoppingListCommandHandler.DefaultSections, neue Standard-Kategorie "Snacks / Suessigkeiten" aus #133, verknuepfte Vorratsschrank-Kategorien #174, Default-Einstellungen/Flags), werden fuer bestehende Listen nie nachgezogen - es fehlen Daten-Migrationen/Backfills.
  • Neue Spalten mit Default-Werten, die fuer Altdaten einen "Feature aus"-Zustand bedeuten.
  • Frontend-Bedingungen, die auf Daten pruefen, die nur neue Listen haben.

Acceptance criteria:

  • Alle bisherigen Features, die listenbezogene Seed-/Default-Daten oder -Flags anlegen, sind inventarisiert (Liste im Issue-Kommentar).
  • Fuer jede gefundene Luecke gibt es eine idempotente Daten-Migration, die bestehende Listen auf den aktuellen Stand bringt (ohne nutzerangepasste Daten zu ueberschreiben, z. B. umbenannte/geloeschte Kategorien).
  • Konvention in ai/roles/00_team_overview.md (bzw. Backend-/Architekt-Rolle) ergaenzt: Jedes Feature, das beim Anlegen einer Liste Daten erzeugt, muss einen Backfill fuer bestehende Listen mitliefern; QA prueft das mit einem Test gegen eine "alte" Liste.
  • Test: Eine vor dem Feature angelegte Liste zeigt nach Migration dasselbe Verhalten wie eine neu angelegte.

Open questions:

  • Konkrete Beispiele aus der Live-Umgebung (welche Liste, welches Feature fehlt) helfen bei der Priorisierung.
## Bug: Bestehende Listen bekommen neue Features nicht bzw. nicht immer **Beobachtung (Mensch, Live-Umgebung):** Wenn ein Listentyp (z. B. Einkaufsliste oder normale To-Do-Liste) um neue Features erweitert wird, kommen diese bei bereits vorher angelegten Listen nicht oder nicht vollstaendig an. Neu angelegte Listen haben sie. **Erwartung:** Jede Liste eines Typs hat immer den vollen Umfang aller fertig entwickelten Features dieses Typs - unabhaengig davon, wann sie angelegt wurde. **Vermutete Ursachen (zu verifizieren):** - Features, die beim Anlegen einer Liste Daten seeden (z. B. Standard-Kategorien in `CreateShoppingListCommandHandler.DefaultSections`, neue Standard-Kategorie "Snacks / Suessigkeiten" aus #133, verknuepfte Vorratsschrank-Kategorien #174, Default-Einstellungen/Flags), werden fuer bestehende Listen nie nachgezogen - es fehlen Daten-Migrationen/Backfills. - Neue Spalten mit Default-Werten, die fuer Altdaten einen "Feature aus"-Zustand bedeuten. - Frontend-Bedingungen, die auf Daten pruefen, die nur neue Listen haben. **Acceptance criteria:** - [ ] Alle bisherigen Features, die listenbezogene Seed-/Default-Daten oder -Flags anlegen, sind inventarisiert (Liste im Issue-Kommentar). - [ ] Fuer jede gefundene Luecke gibt es eine idempotente Daten-Migration, die bestehende Listen auf den aktuellen Stand bringt (ohne nutzerangepasste Daten zu ueberschreiben, z. B. umbenannte/geloeschte Kategorien). - [ ] Konvention in `ai/roles/00_team_overview.md` (bzw. Backend-/Architekt-Rolle) ergaenzt: Jedes Feature, das beim Anlegen einer Liste Daten erzeugt, muss einen Backfill fuer bestehende Listen mitliefern; QA prueft das mit einem Test gegen eine "alte" Liste. - [ ] Test: Eine vor dem Feature angelegte Liste zeigt nach Migration dasselbe Verhalten wie eine neu angelegte. **Open questions:** - Konkrete Beispiele aus der Live-Umgebung (welche Liste, welches Feature fehlt) helfen bei der Priorisierung.
lena self-assigned this 2026-09-28 17:20:51 +02:00
Author
Collaborator

Claimed (explizit vom Menschen angefordert). Plan: Inventar aller listenbezogenen Seed-/Default-Daten beim Anlegen, idempotenter Backfill fuer Luecken (nutzerangepasste Daten bleiben unangetastet), Konvention in 00_team_overview.md, Test alte Liste vs. neue Liste.

Claimed (explizit vom Menschen angefordert). Plan: Inventar aller listenbezogenen Seed-/Default-Daten beim Anlegen, idempotenter Backfill fuer Luecken (nutzerangepasste Daten bleiben unangetastet), Konvention in 00_team_overview.md, Test alte Liste vs. neue Liste.
Author
Collaborator

Erledigt in 0749301c (Fix) und 7f9c080c (Konvention).

Inventar: listenbezogene Seed-/Default-Daten beim Anlegen

Listentyp Seed beim Anlegen Status alter Listen
Einkaufsliste Standard-Sektionen (#90: 14 Stueck, #107: 4 neue Icons, #133: Snacks / Suessigkeiten) Luecke - nie nachgezogen, jetzt behoben
Vorratsschrank keine eigenen Kategorien mehr (#174: nutzt die der verknuepften Einkaufsliste) automatisch mit behoben
To-Do-Liste Kategorie "General" (#80) bereits per Migration nachgezogen, ok
Prioritaetsliste PriorityMatrixFactor (#91) wird immer beim Anlegen gesetzt, ok
Packliste nichts ok
alle Typen Sidebar-Reihenfolge (#149) per Migration nachgezogen, Frontend haengt fehlende Eintraege an, ok
alle Typen Archiv/Farbe/Icon-Spalten Default = bisheriges Verhalten, ok
Einkaufsliste Produkt->Sektion-Wissen (#190) wird bei alten und neuen Listen gleich gelernt, keine Luecke

Fix: Die Standard-Sektionen stehen jetzt in einem versionierten Katalog (ShoppingListDefaultSections, Version 3). Jede Einkaufsliste merkt sich ihre Katalog-Version (neue Spalte DefaultSectionsVersion, bestehende Listen = 0). Ein idempotenter Backfill beim Start ergaenzt fehlende Sektionen (Abgleich per Name ohne Gross-/Kleinschreibung, hinten angehaengt, damit die eigene Reihenfolge bleibt), ersetzt Icons nur, wenn sie noch exakt dem alten Standard-Icon entsprechen, laesst IsDefault unangetastet und setzt die Liste dann auf die aktuelle Version. Kuenftige Katalog-Aenderungen: Version erhoehen und Eintrag anpassen, der Backfill erledigt den Rest - und eine danach geloeschte Sektion kommt nie wieder.

Bekannte Grenze (einmalig, nur fuer Listen von vor heute): Es gibt keine Aufzeichnung, welche Standard-Sektionen Nutzer frueher geloescht oder umbenannt haben. Eine vor heute geloeschte bzw. umbenannte Standard-Sektion taucht daher einmalig wieder auf (leer, also in der Listenansicht seit #107 ausgeblendet). Ab jetzt werden Loeschungen respektiert.

Tests: 5 neue Tests in ShoppingListDefaultSectionsTests (alte Liste vor #107/#133 hat danach exakt dieselben Sektionen und Icons wie eine neue; reine "General"-Liste bekommt alles und behaelt ihren Standard; eigene Icons und Namen in anderer Schreibweise bleiben; eine bei aktueller Version geloeschte Sektion wird nicht neu angelegt; ein zweiter Lauf aendert nichts) plus eine Versions-Pruefung im Create-Test. Backend 1039/63/119 und Frontend 1461 gruen. Im lokalen Review-Container verifiziert: "Wocheneinkauf" hat 13 Sektionen bekommen, das alte Kaese-Icon wurde ersetzt.

Konvention: 00_team_overview.md ("Existing lists get every feature too"), das Design-Template des Architekten (Abschnitt Backfill) und die QA-Testliste (Test gegen eine "alte" Liste) sind ergaenzt.

Erledigt in 0749301c (Fix) und 7f9c080c (Konvention). **Inventar: listenbezogene Seed-/Default-Daten beim Anlegen** | Listentyp | Seed beim Anlegen | Status alter Listen | |---|---|---| | Einkaufsliste | Standard-Sektionen (#90: 14 Stueck, #107: 4 neue Icons, #133: Snacks / Suessigkeiten) | **Luecke** - nie nachgezogen, jetzt behoben | | Vorratsschrank | keine eigenen Kategorien mehr (#174: nutzt die der verknuepften Einkaufsliste) | automatisch mit behoben | | To-Do-Liste | Kategorie "General" (#80) | bereits per Migration nachgezogen, ok | | Prioritaetsliste | PriorityMatrixFactor (#91) | wird immer beim Anlegen gesetzt, ok | | Packliste | nichts | ok | | alle Typen | Sidebar-Reihenfolge (#149) | per Migration nachgezogen, Frontend haengt fehlende Eintraege an, ok | | alle Typen | Archiv/Farbe/Icon-Spalten | Default = bisheriges Verhalten, ok | | Einkaufsliste | Produkt->Sektion-Wissen (#190) | wird bei alten und neuen Listen gleich gelernt, keine Luecke | **Fix:** Die Standard-Sektionen stehen jetzt in einem versionierten Katalog (`ShoppingListDefaultSections`, Version 3). Jede Einkaufsliste merkt sich ihre Katalog-Version (neue Spalte `DefaultSectionsVersion`, bestehende Listen = 0). Ein idempotenter Backfill beim Start ergaenzt fehlende Sektionen (Abgleich per Name ohne Gross-/Kleinschreibung, hinten angehaengt, damit die eigene Reihenfolge bleibt), ersetzt Icons nur, wenn sie noch exakt dem alten Standard-Icon entsprechen, laesst IsDefault unangetastet und setzt die Liste dann auf die aktuelle Version. Kuenftige Katalog-Aenderungen: Version erhoehen und Eintrag anpassen, der Backfill erledigt den Rest - und eine danach geloeschte Sektion kommt nie wieder. **Bekannte Grenze (einmalig, nur fuer Listen von vor heute):** Es gibt keine Aufzeichnung, welche Standard-Sektionen Nutzer frueher geloescht oder umbenannt haben. Eine vor heute geloeschte bzw. umbenannte Standard-Sektion taucht daher einmalig wieder auf (leer, also in der Listenansicht seit #107 ausgeblendet). Ab jetzt werden Loeschungen respektiert. **Tests:** 5 neue Tests in `ShoppingListDefaultSectionsTests` (alte Liste vor #107/#133 hat danach exakt dieselben Sektionen und Icons wie eine neue; reine "General"-Liste bekommt alles und behaelt ihren Standard; eigene Icons und Namen in anderer Schreibweise bleiben; eine bei aktueller Version geloeschte Sektion wird nicht neu angelegt; ein zweiter Lauf aendert nichts) plus eine Versions-Pruefung im Create-Test. Backend 1039/63/119 und Frontend 1461 gruen. Im lokalen Review-Container verifiziert: "Wocheneinkauf" hat 13 Sektionen bekommen, das alte Kaese-Icon wurde ersetzt. **Konvention:** 00_team_overview.md ("Existing lists get every feature too"), das Design-Template des Architekten (Abschnitt Backfill) und die QA-Testliste (Test gegen eine "alte" Liste) sind ergaenzt.
lena 2026-09-28 17:41:55 +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#213
No description provided.