Barcode-Scan (Einkaufsliste & Vorratsschrank) — Produkttyp/generische Bezeichnung statt exakter Markenbezeichnung anzeigen #148

Closed
opened 2026-09-01 14:13:08 +02:00 by lena · 3 comments
lena commented 2026-09-01 14:13:08 +02:00 (Migrated from git.butzei.de)

Story: Barcode-Scan (Einkaufsliste & Vorratsschrank) — Produkttyp/generische Bezeichnung statt exakter Markenbezeichnung anzeigen

As a Nutzer, der ein Produkt scannt,
I want to eine verständliche, generische Produktbezeichnung sehen (z. B. "Milchersatz von vly"),
so that ich das Produkt auch dann wiedererkenne, wenn ich mich an die genaue Marketing-Bezeichnung
nicht erinnere.

Background

Aktuell wird beim Scannen die exakte Produktbezeichnung aus der Barcode-Quelle übernommen (z. B.
"vly High Protein Bio v1.0" statt "Milchersatz von vly"). Das erschwert das Wiedererkennen. Die App
nutzt laut #94/#115/#116 Open Food Facts als Datenquelle für Barcode-Lookups.

Acceptance criteria:

  • Architekt/Backend prüfen, ob Open Food Facts (oder die aktuell genutzte Quelle) ein Feld für
    eine generische/Kategorie-Bezeichnung liefert (z. B. generic_name, categories,
    product_name vs. brands) und ob sich daraus eine sinnvollere Standardbezeichnung ableiten
    lässt.
  • Falls ein geeignetes Feld existiert: neu gescannte Produkte übernehmen standardmäßig die
    generische Bezeichnung statt der exakten Markenbezeichnung (oder zeigen beides, z. B.
    "Milchersatz von vly" mit der exakten Bezeichnung als Zusatzinfo).
  • Falls kein geeignetes Feld existiert: das wird dokumentiert und alternative Lösungsansätze
    werden vorgeschlagen (z. B. eigene Kategorie-Zuordnung, KI-gestützte Zusammenfassung analog
    zu #95).

Out of scope for this story:

  • Rückwirkende Korrektur bereits gescannter/gespeicherter Produkte.

Open questions: (escalate to human if unanswered)

  • Soll die generische Bezeichnung die exakte ersetzen, oder soll die exakte als Zusatzinfo (z. B.
    Tooltip) erhalten bleiben?
# Story: Barcode-Scan (Einkaufsliste & Vorratsschrank) — Produkttyp/generische Bezeichnung statt exakter Markenbezeichnung anzeigen **As a** Nutzer, der ein Produkt scannt, **I want to** eine verständliche, generische Produktbezeichnung sehen (z. B. "Milchersatz von vly"), **so that** ich das Produkt auch dann wiedererkenne, wenn ich mich an die genaue Marketing-Bezeichnung nicht erinnere. ## Background Aktuell wird beim Scannen die exakte Produktbezeichnung aus der Barcode-Quelle übernommen (z. B. "vly High Protein Bio v1.0" statt "Milchersatz von vly"). Das erschwert das Wiedererkennen. Die App nutzt laut `#94`/`#115`/`#116` Open Food Facts als Datenquelle für Barcode-Lookups. **Acceptance criteria:** - [ ] Architekt/Backend prüfen, ob Open Food Facts (oder die aktuell genutzte Quelle) ein Feld für eine generische/Kategorie-Bezeichnung liefert (z. B. `generic_name`, `categories`, `product_name` vs. `brands`) und ob sich daraus eine sinnvollere Standardbezeichnung ableiten lässt. - [ ] Falls ein geeignetes Feld existiert: neu gescannte Produkte übernehmen standardmäßig die generische Bezeichnung statt der exakten Markenbezeichnung (oder zeigen beides, z. B. "Milchersatz von vly" mit der exakten Bezeichnung als Zusatzinfo). - [ ] Falls kein geeignetes Feld existiert: das wird dokumentiert und alternative Lösungsansätze werden vorgeschlagen (z. B. eigene Kategorie-Zuordnung, KI-gestützte Zusammenfassung analog zu `#95`). **Out of scope for this story:** - Rückwirkende Korrektur bereits gescannter/gespeicherter Produkte. **Open questions:** (escalate to human if unanswered) - Soll die generische Bezeichnung die exakte ersetzen, oder soll die exakte als Zusatzinfo (z. B. Tooltip) erhalten bleiben?
lena commented 2026-09-02 18:21:45 +02:00 (Migrated from git.butzei.de)

Open question resolved (human input): the generic/category name replaces the exact brand-specific name shown to the user (not kept alongside as a tooltip). Proceeding on that basis when this is picked up.

Open question resolved (human input): the generic/category name replaces the exact brand-specific name shown to the user (not kept alongside as a tooltip). Proceeding on that basis when this is picked up.
lena self-assigned this 2026-09-04 12:14:58 +02:00
Collaborator

Claiming this. Scope decision (confirmed with the human in this session, given the story's own open question): the generic name replaces the exact marketing name rather than being shown alongside it - smaller scope, no schema change. Plan: Open Food Facts exposes generic_name/generic_name_de fields (distinct from product_name/product_name_de, which OpenFoodFactsClient.cs already maps per #116); prefer generic_name_de, then generic_name, then fall back to today's product_name_de/product_name behavior when neither generic field is populated (Open Food Facts leaves it blank on many products). Change is scoped to OpenFoodFactsClient.cs's name-selection logic plus its tests - no DTO/entity/migration changes needed.

Claiming this. Scope decision (confirmed with the human in this session, given the story's own open question): the generic name replaces the exact marketing name rather than being shown alongside it - smaller scope, no schema change. Plan: Open Food Facts exposes generic_name/generic_name_de fields (distinct from product_name/product_name_de, which OpenFoodFactsClient.cs already maps per `#116`); prefer generic_name_de, then generic_name, then fall back to today's product_name_de/product_name behavior when neither generic field is populated (Open Food Facts leaves it blank on many products). Change is scoped to OpenFoodFactsClient.cs's name-selection logic plus its tests - no DTO/entity/migration changes needed.
Collaborator

Done and pushed (be9b7bd on master). Scope: OpenFoodFactsClient now prefers Open Food Facts' generic_name/generic_name_de fields over product_name/product_name_de when picking the name to suggest on a barcode scan (Shopping and Pantry both go through this same client) - e.g. "Milchersatz von vly" instead of "vly High Protein Bio v1.0". Falls back through generic_name_de -> generic_name -> product_name_de -> product_name (unchanged #116 behavior) since Open Food Facts leaves the generic fields blank on many products. Per the story's open question, the generic name replaces the exact one outright rather than showing both - no DTO/entity/migration changes needed. Tests: 3 new cases in OpenFoodFactsClientTests.cs covering the generic-over-product preference (German and non-German generic name), plus the full-fallback-through path when no generic name exists at all; full backend build and non-Docker test suite green, frontend build+tests green. Docker-dependent DB integration tests and the local review container rebuild could not be verified this cycle - Docker Desktop was not responding in this sandbox despite a restart attempt (unrelated to this change, which touches no DB/entity code). Out of scope per the story: retroactive correction of already-scanned/stored product names.

Done and pushed (be9b7bd on master). Scope: OpenFoodFactsClient now prefers Open Food Facts' generic_name/generic_name_de fields over product_name/product_name_de when picking the name to suggest on a barcode scan (Shopping and Pantry both go through this same client) - e.g. "Milchersatz von vly" instead of "vly High Protein Bio v1.0". Falls back through generic_name_de -> generic_name -> product_name_de -> product_name (unchanged #116 behavior) since Open Food Facts leaves the generic fields blank on many products. Per the story's open question, the generic name replaces the exact one outright rather than showing both - no DTO/entity/migration changes needed. Tests: 3 new cases in OpenFoodFactsClientTests.cs covering the generic-over-product preference (German and non-German generic name), plus the full-fallback-through path when no generic name exists at all; full backend build and non-Docker test suite green, frontend build+tests green. Docker-dependent DB integration tests and the local review container rebuild could not be verified this cycle - Docker Desktop was not responding in this sandbox despite a restart attempt (unrelated to this change, which touches no DB/entity code). Out of scope per the story: retroactive correction of already-scanned/stored product names.
lena closed this issue 2026-09-04 12:20:17 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
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#148
No description provided.