Globale, nutzeruebergreifende Produkt-Kategorie-Datenbank fuer Einkaufsliste und Vorratsschrank #212

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

Story: Globale Produkt-Kategorie-Datenbank ueber alle Nutzer hinweg

As a Nutzer der Einkaufsliste oder des Vorratsschranks,
I want to dass neue Produkte automatisch die passende Kategorie bekommen - gelernt aus allen Listen aller Nutzer,
so that ich Kategorien kaum noch selbst zuordnen muss, auch auf einer ganz neuen Liste.

Kontext (verifiziert im Code / Historie):

  • Die namensbasierte Wissensbasis ProductSectionKnowledgeEntity ist app-weit (#178 wurde nach Rueckmeldung wieder auf app-weit zurueckgedreht), wird aber nur in Einkaufslisten-Texteingabe-Flows genutzt - der Vorratsschrank hat keine serverseitige Kategorie-Wissensbasis fuer eingetippte Produkte.
  • Die Barcode-Wissensbasis aus #190 (ProductBarcodeKnowledgeEntity) ist bewusst NUR pro Einkaufsliste + verknuepftem Vorratsschrank gescopt, nicht nutzeruebergreifend.
  • Wunsch des Menschen: eine im Hintergrund gepflegte Datenbank ueber alle Nutzer hinweg, damit Kategorien direkt mit angegeben werden.

Acceptance criteria:

  • Eine app-weite (nutzeruebergreifende) Zuordnung Produkt -> generische Kategorie wird sowohl von der Einkaufsliste als auch vom Vorratsschrank gespeist und genutzt - fuer Texteingabe (inkl. Smart-Add/Mehrzeilig) und Barcode-Scan.
  • Beim Anlegen eines Produkts auf einer beliebigen Liste wird die Kategorie aus dieser Datenbank vorausgewaehlt, gemappt auf die gleichnamige/passende Kategorie der konkreten Liste; nur wenn nichts passt, bleibt die bisherige Nachfrage/Standard-Kategorie.
  • Die Barcode-Zuordnung Barcode -> Produktname/Kategorie wird ebenfalls nutzeruebergreifend geteilt (Datenmodell/Scope-Aenderung gegenueber #190).
  • Es werden nur generische Daten geteilt (Produktname, Kategorie-Name, Barcode) - keine Mengen, Kommentare, Nutzer- oder Listenbezuege.

Open questions (escalate to human if unanswered):

  • Konfliktregel, wenn verschiedene Nutzer dasselbe Produkt unterschiedlich kategorisieren: Mehrheit / zuletzt gewinnt?
  • Soll die eigene, listenbezogene Zuordnung weiterhin Vorrang vor der globalen haben?
## Story: Globale Produkt-Kategorie-Datenbank ueber alle Nutzer hinweg **As a** Nutzer der Einkaufsliste oder des Vorratsschranks, **I want to** dass neue Produkte automatisch die passende Kategorie bekommen - gelernt aus allen Listen aller Nutzer, **so that** ich Kategorien kaum noch selbst zuordnen muss, auch auf einer ganz neuen Liste. **Kontext (verifiziert im Code / Historie):** - Die namensbasierte Wissensbasis `ProductSectionKnowledgeEntity` ist app-weit (#178 wurde nach Rueckmeldung wieder auf app-weit zurueckgedreht), wird aber nur in Einkaufslisten-Texteingabe-Flows genutzt - der Vorratsschrank hat keine serverseitige Kategorie-Wissensbasis fuer eingetippte Produkte. - Die Barcode-Wissensbasis aus #190 (`ProductBarcodeKnowledgeEntity`) ist bewusst NUR pro Einkaufsliste + verknuepftem Vorratsschrank gescopt, nicht nutzeruebergreifend. - Wunsch des Menschen: eine im Hintergrund gepflegte Datenbank ueber alle Nutzer hinweg, damit Kategorien direkt mit angegeben werden. **Acceptance criteria:** - [ ] Eine app-weite (nutzeruebergreifende) Zuordnung Produkt -> generische Kategorie wird sowohl von der Einkaufsliste als auch vom Vorratsschrank gespeist und genutzt - fuer Texteingabe (inkl. Smart-Add/Mehrzeilig) und Barcode-Scan. - [ ] Beim Anlegen eines Produkts auf einer beliebigen Liste wird die Kategorie aus dieser Datenbank vorausgewaehlt, gemappt auf die gleichnamige/passende Kategorie der konkreten Liste; nur wenn nichts passt, bleibt die bisherige Nachfrage/Standard-Kategorie. - [ ] Die Barcode-Zuordnung Barcode -> Produktname/Kategorie wird ebenfalls nutzeruebergreifend geteilt (Datenmodell/Scope-Aenderung gegenueber #190). - [ ] Es werden nur generische Daten geteilt (Produktname, Kategorie-Name, Barcode) - keine Mengen, Kommentare, Nutzer- oder Listenbezuege. **Open questions (escalate to human if unanswered):** - Konfliktregel, wenn verschiedene Nutzer dasselbe Produkt unterschiedlich kategorisieren: Mehrheit / zuletzt gewinnt? - Soll die eigene, listenbezogene Zuordnung weiterhin Vorrang vor der globalen haben?
lena self-assigned this 2026-09-28 22:45:47 +02:00
Author
Collaborator

Start: Claim durch den autonomen Loop (auf Wunsch des Menschen). Entscheidungen des Menschen (vorab im Chat abgefragt):

  • Konfliktregel global: zuletzt gewinnt (Upsert, kein Zaehlen).
  • Die eigene, listenbezogene Zuordnung (Liste + verknuepfter Vorratsschrank) hat Vorrang; global nur, wenn lokal nichts bekannt ist.
  • Globale Kategorie existiert auf der Liste nicht: unkategorisiert lassen (keine Kategorie wird neu angelegt).
  • Lernquellen: neues Produkt mit Kategorie, Produkt verschieben, Barcode-Scan und Umbenennen, CSV-Import der Barcode-Wissensbasis.
  • Startdaten: die Vorgabe-CSV (input/Vordefinierte Sektionen & Zuordnungsliste.csv) plus alles bisher pro Liste Gelernte.
  • Vorauswahl: automatisch beim Speichern (wie heute), kein neues UI.

Plan: zwei neue app-weite Tabellen (Produktname -> Kategoriename, Barcode -> Produktname/Kategoriename), nur generische Daten, keine Listen-/Nutzerbezuege. Die bestehenden listenbezogenen Tabellen bleiben als vorrangige lokale Ebene. Der Vorratsschrank bekommt bei Texteingabe dieselbe Aufloesung (lokal, dann global).

Start: Claim durch den autonomen Loop (auf Wunsch des Menschen). Entscheidungen des Menschen (vorab im Chat abgefragt): - Konfliktregel global: zuletzt gewinnt (Upsert, kein Zaehlen). - Die eigene, listenbezogene Zuordnung (Liste + verknuepfter Vorratsschrank) hat Vorrang; global nur, wenn lokal nichts bekannt ist. - Globale Kategorie existiert auf der Liste nicht: unkategorisiert lassen (keine Kategorie wird neu angelegt). - Lernquellen: neues Produkt mit Kategorie, Produkt verschieben, Barcode-Scan und Umbenennen, CSV-Import der Barcode-Wissensbasis. - Startdaten: die Vorgabe-CSV (input/Vordefinierte Sektionen & Zuordnungsliste.csv) plus alles bisher pro Liste Gelernte. - Vorauswahl: automatisch beim Speichern (wie heute), kein neues UI. Plan: zwei neue app-weite Tabellen (Produktname -> Kategoriename, Barcode -> Produktname/Kategoriename), nur generische Daten, keine Listen-/Nutzerbezuege. Die bestehenden listenbezogenen Tabellen bleiben als vorrangige lokale Ebene. Der Vorratsschrank bekommt bei Texteingabe dieselbe Aufloesung (lokal, dann global).
Author
Collaborator

Erledigt (Commits auf master: feat(#212) Tabellen + Logik, test(#212)).

Umfang

  • Zwei neue app-weite Tabellen mit nur generischen Daten: Produktname (normalisiert) -> Kategoriename sowie Barcode -> Produktname + Kategoriename. Keine Listen-, Nutzer-, Mengen- oder Kommentarbezuege.
  • Gespeist durch: Anlegen mit Kategorie (Einkaufsliste und Vorratsschrank, inkl. Smart-Add/Mehrzeilig), Verschieben in eine andere Kategorie, Barcode-Scan (beide Seiten), Umbenennen barcode-tragender Produkte, CSV-Import der Barcode-Wissensbasis.
  • Genutzt: Anlegen ohne Kategorie (Einkaufsliste und neu auch Vorratsschrank) und Scan eines unbekannten Barcodes. Reihenfolge: eigene Liste -> global -> (bei Barcodes) Open Food Facts. Die globale Kategorie wird nur auf eine gleichnamige vorhandene Kategorie der Liste gemappt; sonst bleibt es bei der bisherigen Nachfrage bzw. Standard-Kategorie.
  • Startdaten: Vorgabe-CSV (210 Namen) plus alles bisher pro Liste Gelernte; lokal nach Migration 211 Namens- und 1 Barcode-Eintrag.

Entscheidungen (vom Menschen vorab): zuletzt gewinnt; eigene Liste zuerst; fehlende Kategorie wird nicht angelegt; alle genannten Lernquellen inkl. CSV-Import; Seed aus CSV + Bestandsdaten; automatische Zuordnung beim Speichern ohne neues UI.

Tests: 11 neue Backend-Tests (GlobalProductKnowledgeTests), gesamte Suite gruen (1063 Checkly.Tests, 63 WebApi.Tests). Migrationen gegen das echte Postgres des Review-Containers angewendet.

Security-Review: keine Findings (Upserts parametrisiert, Kategorie-IDs vor Nutzung pro Liste validiert). Bewusst akzeptierter Trade-off: durch zuletzt-gewinnt kann jeder Nutzer einen Vorschlag fuer alle ueberschreiben - betrifft nur Vorschlaege, die beim Scan bestaetigt bzw. per Verschieben korrigiert werden.

Bekannte Grenze: Produkte, die offline angelegt werden, bleiben bis zur Synchronisierung unkategorisiert (unveraendert zum bisherigen Verhalten).

Erledigt (Commits auf master: feat(#212) Tabellen + Logik, test(#212)). **Umfang** - Zwei neue app-weite Tabellen mit nur generischen Daten: Produktname (normalisiert) -> Kategoriename sowie Barcode -> Produktname + Kategoriename. Keine Listen-, Nutzer-, Mengen- oder Kommentarbezuege. - Gespeist durch: Anlegen mit Kategorie (Einkaufsliste und Vorratsschrank, inkl. Smart-Add/Mehrzeilig), Verschieben in eine andere Kategorie, Barcode-Scan (beide Seiten), Umbenennen barcode-tragender Produkte, CSV-Import der Barcode-Wissensbasis. - Genutzt: Anlegen ohne Kategorie (Einkaufsliste und neu auch Vorratsschrank) und Scan eines unbekannten Barcodes. Reihenfolge: eigene Liste -> global -> (bei Barcodes) Open Food Facts. Die globale Kategorie wird nur auf eine gleichnamige vorhandene Kategorie der Liste gemappt; sonst bleibt es bei der bisherigen Nachfrage bzw. Standard-Kategorie. - Startdaten: Vorgabe-CSV (210 Namen) plus alles bisher pro Liste Gelernte; lokal nach Migration 211 Namens- und 1 Barcode-Eintrag. **Entscheidungen (vom Menschen vorab)**: zuletzt gewinnt; eigene Liste zuerst; fehlende Kategorie wird nicht angelegt; alle genannten Lernquellen inkl. CSV-Import; Seed aus CSV + Bestandsdaten; automatische Zuordnung beim Speichern ohne neues UI. **Tests**: 11 neue Backend-Tests (GlobalProductKnowledgeTests), gesamte Suite gruen (1063 Checkly.Tests, 63 WebApi.Tests). Migrationen gegen das echte Postgres des Review-Containers angewendet. **Security-Review**: keine Findings (Upserts parametrisiert, Kategorie-IDs vor Nutzung pro Liste validiert). Bewusst akzeptierter Trade-off: durch zuletzt-gewinnt kann jeder Nutzer einen Vorschlag fuer alle ueberschreiben - betrifft nur Vorschlaege, die beim Scan bestaetigt bzw. per Verschieben korrigiert werden. **Bekannte Grenze**: Produkte, die offline angelegt werden, bleiben bis zur Synchronisierung unkategorisiert (unveraendert zum bisherigen Verhalten).
lena 2026-09-29 08:50:03 +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#212
No description provided.