Bug — Speisekammer schreibt Soll-Menge-Artikel nur beim Check-Out auf die Einkaufsliste, nicht beim Setzen/Erhöhen der Soll-Menge oder bei manueller Anzahl-Änderung #195
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#195
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?
Story: Soll-Menge-Unterschreitung wird bei jeder relevanten Änderung geprüft, nicht nur beim Check-Out
As a Speisekammer-Nutzer,
I want to dass die Prüfung "Anzahl unter Soll-Menge -> automatisch auf die Einkaufsliste schreiben" nach jeder Änderung läuft, die dieses Verhältnis beeinflusst — nicht nur nach einem Check-Out,
so that ich mich darauf verlassen kann, dass ein Produkt automatisch auf der Einkaufsliste landet, sobald seine Soll-Menge höher ist als der aktuelle Bestand — egal ob das durch Auschecken, durch manuelles Ändern der Anzahl oder durch nachträgliches Setzen/Erhöhen der Soll-Menge selbst entstanden ist.
Bug-Beschreibung (im Test-System reproduziert): Ein Speisekammer-Produkt mit vorhandenem Bestand unterhalb einer neu gesetzten Soll-Menge erscheint nicht automatisch auf der Einkaufsliste. Ursache im Code:
PantryLowStockShoppingWriter.WriteMissingAmountIfBelowTargetwird aktuell ausschließlich ausCheckOutPantryProductCommandHandleraufgerufen. WederSetPantryProductTargetQuantityCommandHandler(Soll-Menge setzen/ändern) nochSetPantryProductQuantityCommandHandler(manuelle Anzahl-Korrektur, z. B. über den Bearbeiten-Dialog) rufen die Prüfung auf. Es existiert außerdem kein wiederkehrender Hintergrundjob, der das nachträglich nachholt (kein Cron/Scheduled Job dafür im Code) — es handelt sich also nicht um eine Verzögerung, sondern um eine echte Lücke: Ohne einen Check-Out passiert schlicht nichts.Acceptance criteria:
SetPantryProductTargetQuantityCommand) löst die Unterschreitungs-Prüfung sofort aus, wenn der aktuelle Bestand bereits unter der neuen Soll-Menge liegt.SetPantryProductQuantityCommand) löst dieselbe Prüfung aus, wenn die neue Anzahl unter der (ggf. vorhandenen) Soll-Menge liegt.PantryLowStockShoppingWriterbzw. deren Nachfolger), keine Duplikation.Out of scope for this story:
Open questions: (escalate to human if unanswered)
Als Bug vom Nutzer im Test-System gemeldet (per Chat): Soll-Menge gesetzt, Produkt erschien nicht auf der Einkaufsliste.
Claiming this. Plan: extract the low-stock check that CheckOutPantryProductCommandHandler already runs via PantryLowStockShoppingWriter and invoke the same call from SetPantryProductTargetQuantityCommandHandler and SetPantryProductQuantityCommandHandler, using the post-change (quantity, target) pair in each case. Adding regression tests for both new call sites plus keeping the existing check-out coverage green.
Fixed and merged to master (
71089637).Scope: PantryLowStockShoppingWriter.WriteMissingAmountIfBelowTarget was only ever invoked from CheckOutPantryProductCommandHandler. Added the same call to SetPantryProductTargetQuantityCommandHandler (after saving the new target) and SetPantryProductQuantityCommandHandler (after saving the new quantity), both using the shared writer so there is no duplicated low-stock logic - matches all four acceptance criteria in the story.
Tests: 4 new regression tests (2 positive + 2 negative cases) covering both new call sites in PantryProductCrudHandlersTests.cs. Also adjusted the data in two pre-existing tests (Updates_the_target_quantity, Preserves_labels_and_comment_count_across_a_target_quantity_change) whose fixture data (quantity 1, target 5) now incidentally triggered the new low-stock write - bumped their quantity to 5 so they stay focused on their own concern. Full local backend suite green: 969 + 52 + 119 tests, 0 failures.
Key decision: reused the existing #94 static writer rather than adding new logic, per the story out-of-scope note - #192 (configurable reorder amount) and #193 (2-day cooldown) build on top of this fix as separate stories.
Note: Forgejo Actions CI stayed in
pendingstate for the whole cycle (no runner appears to have picked up the jobs) - verified via full local dotnet build + test run instead, per the loop CLAUDE.md fallback. Flagging in case the runner needs attention.