robert/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 3 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Speisekammer — Produkt bei Anzahl 0 aus der Liste entfernen, aber in Scan-Station-Historie rückgängig machbar halten #194

New issue
Closed
opened 2026-09-12 00:30:35 +02:00 by lena · 2 comments
lena commented 2026-09-12 00:30:35 +02:00
Collaborator
Copy link

Story: Auschecken auf 0 entfernt Produkt aus der aktiven Liste, bleibt aber über die Historie rückgängig machbar

As a Speisekammer-Nutzer,
I want to dass ein Produkt, dessen Anzahl durch Auschecken auf 0 fällt, nicht länger mit "0" in der aktiven Speisekammer-Liste stehen bleibt, sondern automatisch verschwindet,
so that die Liste nur tatsächlich vorhandene Produkte zeigt und ich nicht ständig 0er-Karteileichen wegräumen muss — ohne dabei die Möglichkeit zu verlieren, einen versehentlichen Check-Out rückgängig zu machen.

Hintergrund: Der bestehende Scan-Station-Undo (#172, InvertPantryActivityEventCommandHandler) invertiert einen Check-In/Check-Out-Aktivitätseintrag, verlangt dafür aber aktuell, dass die zugehörige PantryProductEntity-Zeile noch existiert ("Cannot invert an event whose product no longer exists."). Ein einfaches Hard-Delete des Produkts bei Anzahl 0 würde dieses Undo also brechen — das muss diese Story mit lösen.

Acceptance criteria:

  • Fällt die Anzahl eines Speisekammer-Produkts durch Check-Out auf 0, verschwindet es aus der aktiven Speisekammer-Ansicht (nicht mehr als Zeile mit Anzahl 0 sichtbar/editierbar).
  • Der zugehörige Check-Out-Aktivitätseintrag bleibt in der Scan-Station-Historie sichtbar und über die bestehende Invert/Undo-Funktion rückgängig machbar — macht ein Nutzer den Check-Out rückgängig, taucht das Produkt mit der wiederhergestellten Anzahl erneut in der aktiven Liste auf.
  • Barcode, Name und Kategorie des Produkts bleiben dauerhaft in der Datenbank erhalten (kein Hard-Delete dieser Stammdaten), auch über die Undo-Fähigkeit hinaus — insbesondere damit ein erneutes Scannen desselben Barcodes später wieder denselben Namen/dieselbe Kategorie vorschlägt (Bezug zu #190s geteilter Produkt-Wissensbasis).
  • Bereits vorhandene Referenzen auf das Produkt (Labels, Kommentare, Soll-Menge, Aktivitäts-Historie) bleiben konsistent nutzbar, solange das Produkt in seinem "verschwundenen" (Anzahl-0) Zustand ist, und werden bei einem Undo/erneuten Check-In wieder normal angezeigt.
  • Ein manuelles Neuanlegen desselben Produkts (z. B. erneuter Scan) während es sich im Anzahl-0-Zustand befindet, führt nicht zu einem doppelten Produkt-Datensatz.

Out of scope for this story:

  • Die Soll-Menge-Übersicht und die Nachbestell-Wartezeit (siehe separate Issues) — diese Story betrifft nur das Sichtbarkeits-/Aufbewahrungsverhalten bei Anzahl 0.
  • Änderungen an der geteilten Produkt-Wissensbasis aus #190 selbst.

Open questions: (escalate to human if unanswered)

  • Technischer Ansatz wird an den Software Architect verwiesen: vermutlich ein Soft-Delete-Flag (z. B. IsHidden/RemovedAt) auf PantryProductEntity statt physischem Löschen, damit Invert/Undo und Stammdaten-Erhalt (Barcode/Name/Kategorie) ohne Bruch funktionieren — keine Entscheidung, die die Story selbst treffen muss.

Als Backlog-Item vom Nutzer eingereicht (per Chat, nicht im laufenden Loop-Zyklus geclaimt).

## Story: Auschecken auf 0 entfernt Produkt aus der aktiven Liste, bleibt aber über die Historie rückgängig machbar **As a** Speisekammer-Nutzer, **I want to** dass ein Produkt, dessen Anzahl durch Auschecken auf 0 fällt, nicht länger mit "0" in der aktiven Speisekammer-Liste stehen bleibt, sondern automatisch verschwindet, **so that** die Liste nur tatsächlich vorhandene Produkte zeigt und ich nicht ständig 0er-Karteileichen wegräumen muss — ohne dabei die Möglichkeit zu verlieren, einen versehentlichen Check-Out rückgängig zu machen. Hintergrund: Der bestehende Scan-Station-Undo (#172, `InvertPantryActivityEventCommandHandler`) invertiert einen Check-In/Check-Out-Aktivitätseintrag, verlangt dafür aber aktuell, dass die zugehörige `PantryProductEntity`-Zeile noch existiert (`"Cannot invert an event whose product no longer exists."`). Ein einfaches Hard-Delete des Produkts bei Anzahl 0 würde dieses Undo also brechen — das muss diese Story mit lösen. **Acceptance criteria:** - [ ] Fällt die Anzahl eines Speisekammer-Produkts durch Check-Out auf 0, verschwindet es aus der aktiven Speisekammer-Ansicht (nicht mehr als Zeile mit Anzahl 0 sichtbar/editierbar). - [ ] Der zugehörige Check-Out-Aktivitätseintrag bleibt in der Scan-Station-Historie sichtbar und über die bestehende Invert/Undo-Funktion rückgängig machbar — macht ein Nutzer den Check-Out rückgängig, taucht das Produkt mit der wiederhergestellten Anzahl erneut in der aktiven Liste auf. - [ ] Barcode, Name und Kategorie des Produkts bleiben dauerhaft in der Datenbank erhalten (kein Hard-Delete dieser Stammdaten), auch über die Undo-Fähigkeit hinaus — insbesondere damit ein erneutes Scannen desselben Barcodes später wieder denselben Namen/dieselbe Kategorie vorschlägt (Bezug zu #190s geteilter Produkt-Wissensbasis). - [ ] Bereits vorhandene Referenzen auf das Produkt (Labels, Kommentare, Soll-Menge, Aktivitäts-Historie) bleiben konsistent nutzbar, solange das Produkt in seinem "verschwundenen" (Anzahl-0) Zustand ist, und werden bei einem Undo/erneuten Check-In wieder normal angezeigt. - [ ] Ein manuelles Neuanlegen desselben Produkts (z. B. erneuter Scan) während es sich im Anzahl-0-Zustand befindet, führt nicht zu einem doppelten Produkt-Datensatz. **Out of scope for this story:** - Die Soll-Menge-Übersicht und die Nachbestell-Wartezeit (siehe separate Issues) — diese Story betrifft nur das Sichtbarkeits-/Aufbewahrungsverhalten bei Anzahl 0. - Änderungen an der geteilten Produkt-Wissensbasis aus #190 selbst. **Open questions:** (escalate to human if unanswered) - Technischer Ansatz wird an den Software Architect verwiesen: vermutlich ein Soft-Delete-Flag (z. B. `IsHidden`/`RemovedAt`) auf `PantryProductEntity` statt physischem Löschen, damit Invert/Undo und Stammdaten-Erhalt (Barcode/Name/Kategorie) ohne Bruch funktionieren — keine Entscheidung, die die Story selbst treffen muss. --- Als Backlog-Item vom Nutzer eingereicht (per Chat, nicht im laufenden Loop-Zyklus geclaimt).
lena self-assigned this 2026-09-28 22:42:08 +02:00
lena commented 2026-09-28 22:42:09 +02:00
Author
Collaborator
Copy link

Start: Claim durch den autonomen Loop (auf Wunsch des Menschen). Architect-Entscheidung zur offenen Frage: Soft-Hide-Flag IsHidden auf dem Speisekammer-Produkt statt Hard-Delete. Check-Out, der die Anzahl auf 0 bringt, setzt IsHidden; jede Operation, die die Anzahl wieder ueber 0 hebt (Check-In, Scan, Invertieren/Rueckgaengig in der Scan-Station-Historie, Anzahl manuell setzen), hebt es wieder auf. Die aktive Liste blendet versteckte Produkte aus; Zeile, Barcode, Name, Kategorie, Labels, Kommentare, Soll-Menge und Historie bleiben unveraendert erhalten. Erneuter Scan desselben Barcodes findet die versteckte Zeile (kein Duplikat); manuelles Neuanlegen mit gleichem Namen belebt die versteckte Zeile wieder statt eine zweite anzulegen. Nur Check-Out versteckt - ein manuell auf 0 gesetztes oder neu mit 0 angelegtes Produkt bleibt sichtbar (AC spricht explizit von Check-Out).

Start: Claim durch den autonomen Loop (auf Wunsch des Menschen). Architect-Entscheidung zur offenen Frage: Soft-Hide-Flag `IsHidden` auf dem Speisekammer-Produkt statt Hard-Delete. Check-Out, der die Anzahl auf 0 bringt, setzt `IsHidden`; jede Operation, die die Anzahl wieder ueber 0 hebt (Check-In, Scan, Invertieren/Rueckgaengig in der Scan-Station-Historie, Anzahl manuell setzen), hebt es wieder auf. Die aktive Liste blendet versteckte Produkte aus; Zeile, Barcode, Name, Kategorie, Labels, Kommentare, Soll-Menge und Historie bleiben unveraendert erhalten. Erneuter Scan desselben Barcodes findet die versteckte Zeile (kein Duplikat); manuelles Neuanlegen mit gleichem Namen belebt die versteckte Zeile wieder statt eine zweite anzulegen. Nur Check-Out versteckt - ein manuell auf 0 gesetztes oder neu mit 0 angelegtes Produkt bleibt sichtbar (AC spricht explizit von Check-Out).
lena commented 2026-09-28 23:11:02 +02:00
Author
Collaborator
Copy link

Erledigt (Commits 4816d695, 443e7d25, 179f9eb9).

Umfang: Neues Soft-Hide-Flag IsHidden auf dem Speisekammer-Produkt (Migration AddPantryProductIsHidden), kein Hard-Delete. Ein Check-Out, der die Anzahl auf 0 bringt, setzt das Flag im selben atomaren UPDATE. Jeder Weg, der die Anzahl wieder ueber 0 hebt (Check-In, erneuter Scan, Invertieren/Loeschen in der Scan-Station-Historie, Anzahl manuell setzen, CSV-Import), hebt es wieder auf. Eine Korrektur in der Historie, die auf 0 faellt, versteckt wieder. Das Produkt behaelt Barcode, Name, Kategorie, Labels, Kommentare, Soll-Menge und Historie. Ein erneuter Scan desselben Barcodes findet dieselbe Zeile. Manuelles Neuanlegen mit gleichem Namen (ohne Beachtung der Gross-/Kleinschreibung) bzw. gleichem Barcode belebt die versteckte Zeile wieder, statt ein Duplikat anzulegen.

Frontend: Die Speisekammer-Seite blendet versteckte Produkte aus (auch fuer die Leer-Anzeige). Beim Scan-Check-Out auf 0 erscheint ein Hinweis-Toast. Der Offline-Spiegel fuer Check-In/-Out wendet dieselbe Regel an, der CSV-Export laesst versteckte Produkte weg. Suche und MHD-Benachrichtigungen ignorieren versteckte Produkte.

Bewusste Entscheidungen: Nur Check-Out versteckt. Ein manuell auf 0 gesetztes Produkt bleibt sichtbar. Bereits vorhandene 0er-Zeilen von vor diesem Update bleiben sichtbar (man weiss nicht, ob sie durch Check-Out entstanden sind). Die Soll-Menge-Uebersicht zeigt versteckte Produkte weiterhin (out of scope). Das Duplizieren eines Vorratsschranks kopiert sie weiterhin mit, wie alle anderen Produkte mit Anzahl 0.

Tests: 13 neue Backend-Tests (PantryProductHideAtZeroTests), 4 neue PantryPage-Tests, 2 neue Offline-Tests. Lokal: Backend 1052+63+119 gruen, Frontend 1485 gruen, Build ok. Self-Review und Security-Review ohne Befund.

Erledigt (Commits 4816d695, 443e7d25, 179f9eb9). **Umfang:** Neues Soft-Hide-Flag `IsHidden` auf dem Speisekammer-Produkt (Migration `AddPantryProductIsHidden`), kein Hard-Delete. Ein Check-Out, der die Anzahl auf 0 bringt, setzt das Flag im selben atomaren UPDATE. Jeder Weg, der die Anzahl wieder ueber 0 hebt (Check-In, erneuter Scan, Invertieren/Loeschen in der Scan-Station-Historie, Anzahl manuell setzen, CSV-Import), hebt es wieder auf. Eine Korrektur in der Historie, die auf 0 faellt, versteckt wieder. Das Produkt behaelt Barcode, Name, Kategorie, Labels, Kommentare, Soll-Menge und Historie. Ein erneuter Scan desselben Barcodes findet dieselbe Zeile. Manuelles Neuanlegen mit gleichem Namen (ohne Beachtung der Gross-/Kleinschreibung) bzw. gleichem Barcode belebt die versteckte Zeile wieder, statt ein Duplikat anzulegen. **Frontend:** Die Speisekammer-Seite blendet versteckte Produkte aus (auch fuer die Leer-Anzeige). Beim Scan-Check-Out auf 0 erscheint ein Hinweis-Toast. Der Offline-Spiegel fuer Check-In/-Out wendet dieselbe Regel an, der CSV-Export laesst versteckte Produkte weg. Suche und MHD-Benachrichtigungen ignorieren versteckte Produkte. **Bewusste Entscheidungen:** Nur Check-Out versteckt. Ein manuell auf 0 gesetztes Produkt bleibt sichtbar. Bereits vorhandene 0er-Zeilen von vor diesem Update bleiben sichtbar (man weiss nicht, ob sie durch Check-Out entstanden sind). Die Soll-Menge-Uebersicht zeigt versteckte Produkte weiterhin (out of scope). Das Duplizieren eines Vorratsschranks kopiert sie weiterhin mit, wie alle anderen Produkte mit Anzahl 0. **Tests:** 13 neue Backend-Tests (PantryProductHideAtZeroTests), 4 neue PantryPage-Tests, 2 neue Offline-Tests. Lokal: Backend 1052+63+119 gruen, Frontend 1485 gruen, Build ok. Self-Review und Security-Review ohne Befund.
lena 2026-09-28 23:11:03 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/in-app-notifications
feature/list-archiving
feature/filter-search
No results found.
Labels
Clear 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 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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
lena
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#194
No description provided.