Bug - Bestehende Listen erhalten neu entwickelte Features nicht (vollstaendig) #213
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#213
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?
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):
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.Acceptance criteria:
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.Open questions:
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.
Erledigt in
0749301c(Fix) und7f9c080c(Konvention).Inventar: listenbezogene Seed-/Default-Daten beim Anlegen
Fix: Die Standard-Sektionen stehen jetzt in einem versionierten Katalog (
ShoppingListDefaultSections, Version 3). Jede Einkaufsliste merkt sich ihre Katalog-Version (neue SpalteDefaultSectionsVersion, 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.