Wiederkehrende Eintraege auf der Einkaufsliste (feste Turnusartikel)

lena commented

2026-09-09 07:57:48 +02:00

Collaborator

Story: Wiederkehrende Eintraege auf der Einkaufsliste (feste Turnusartikel)

As a Mitglied einer Einkaufsliste,
I want to ein Produkt als wiederkehrend markieren (z. B. Toilettenpapier alle 2 Wochen),
so that ich Standardartikel nicht jedes Mal von Hand neu eintragen muss, sondern sie automatisch wieder auf der Liste erscheinen.

Kontext (verifiziert im Code): Todos haben bereits eine vollstaendige Wiederholungsregel (RecurrencePicker.tsx, RecurrenceRule auf TodoEntity, inkl. Turnus-Zuweisung aus #157) - Einkaufslisten-Produkte (ShoppingProductEntity) haben aktuell kein Aequivalent. Das ist unabhaengig vom Vorratsschrank-basierten "unter Zielmenge nachfuellen"-Mechanismus (PantryLowStockShoppingWriter) gedacht: dieser setzt eine Vorratsschrank-Eintragung mit Zielmenge voraus, waehrend viele Einkaufslisten-Haushalte Standardartikel gar nicht im Vorratsschrank pflegen.

Acceptance criteria:

Ein Einkaufslisten-Produkt kann mit einem Wiederholungsintervall versehen werden (z. B. taeglich/woechentlich/alle N Wochen - gleiche Regel-Bausteine wie beim bestehenden Todo-RecurrencePicker, soweit sinnvoll uebertragbar).
Wird ein wiederkehrendes Produkt abgehakt (von der aktiven Liste entfernt), erscheint es gemaess seinem Intervall automatisch wieder auf der aktiven Liste, ohne dass jemand es erneut eintippen muss.
Das Wiederholungsintervall ist in der Produktbearbeitung sichtbar und aenderbar, aehnlich wie beim Todo-Pendant.
Ein normales, nicht-wiederkehrendes Produkt verhaelt sich exakt wie bisher (die Funktion ist rein additiv).

Out of scope for this story:

Automatische Erkennung, welche Artikel "typischerweise" wiederkehren - die Markierung erfolgt manuell durch den Nutzer.
Aenderungen am Vorratsschrank-Zielmengen-Mechanismus.

Open questions: (escalate to human if unanswered)

Keine - uebertraegt ein bereits fuer Todos gebautes und bewaehrtes Muster (Wiederholungsregel) auf einen zweiten Listentyp, mit demselben UI-Baustein soweit er passt.

## Story: Wiederkehrende Eintraege auf der Einkaufsliste (feste Turnusartikel) **As a** Mitglied einer Einkaufsliste, **I want to** ein Produkt als wiederkehrend markieren (z. B. Toilettenpapier alle 2 Wochen), **so that** ich Standardartikel nicht jedes Mal von Hand neu eintragen muss, sondern sie automatisch wieder auf der Liste erscheinen. **Kontext (verifiziert im Code):** Todos haben bereits eine vollstaendige Wiederholungsregel (RecurrencePicker.tsx, RecurrenceRule auf TodoEntity, inkl. Turnus-Zuweisung aus #157) - Einkaufslisten-Produkte (ShoppingProductEntity) haben aktuell kein Aequivalent. Das ist unabhaengig vom Vorratsschrank-basierten "unter Zielmenge nachfuellen"-Mechanismus (PantryLowStockShoppingWriter) gedacht: dieser setzt eine Vorratsschrank-Eintragung mit Zielmenge voraus, waehrend viele Einkaufslisten-Haushalte Standardartikel gar nicht im Vorratsschrank pflegen. **Acceptance criteria:** - [ ] Ein Einkaufslisten-Produkt kann mit einem Wiederholungsintervall versehen werden (z. B. taeglich/woechentlich/alle N Wochen - gleiche Regel-Bausteine wie beim bestehenden Todo-RecurrencePicker, soweit sinnvoll uebertragbar). - [ ] Wird ein wiederkehrendes Produkt abgehakt (von der aktiven Liste entfernt), erscheint es gemaess seinem Intervall automatisch wieder auf der aktiven Liste, ohne dass jemand es erneut eintippen muss. - [ ] Das Wiederholungsintervall ist in der Produktbearbeitung sichtbar und aenderbar, aehnlich wie beim Todo-Pendant. - [ ] Ein normales, nicht-wiederkehrendes Produkt verhaelt sich exakt wie bisher (die Funktion ist rein additiv). **Out of scope for this story:** - Automatische Erkennung, welche Artikel "typischerweise" wiederkehren - die Markierung erfolgt manuell durch den Nutzer. - Aenderungen am Vorratsschrank-Zielmengen-Mechanismus. **Open questions:** (escalate to human if unanswered) - Keine - uebertraegt ein bereits fuer Todos gebautes und bewaehrtes Muster (Wiederholungsregel) auf einen zweiten Listentyp, mit demselben UI-Baustein soweit er passt.

lena added the

priority/could

type/feature

labels

2026-09-09 07:57:48 +02:00

lena referenced this issue

2026-09-11 22:14:08 +02:00

Mehrfachauswahl (mehrere Produkte auf einmal loeschen) fuer Einkaufsliste und Vorratsschrank #187

lena self-assigned this

2026-09-11 22:24:15 +02:00

lena added the

status/claimed

label

2026-09-11 22:24:15 +02:00

lena commented

2026-09-11 22:24:34 +02:00

Author

Collaborator

Claiming this for the current autonomous cycle. Plan: mirror the existing Todo RecurrenceRule pattern (RecurrencePicker.tsx, TodoEntity.RecurrenceRule, the roll-forward/reappear mechanism used for recurring todos) onto ShoppingProductEntity - add a recurrence-rule column, expose it in product editing via the same RecurrencePicker component where the rule vocabulary fits shopping items, and wire the recurring-product reappearance into whatever mechanism actually re-adds/reactivates a checked-off product (need to check whether shopping products are soft-deactivated or deleted on check-off before finalizing the reappearance design - investigating the code now before writing anything). No open questions per the issue body. Not overlapping with #185 (comment notifications) or #181/#186/#187 (already shipped).

lena referenced this issue from a commit

2026-09-11 22:54:23 +02:00

feat(#183): recurring items on the shopping list

lena commented

2026-09-11 22:58:29 +02:00

Author

Collaborator

Implemented and merged (c2511a3e).

Scope: a shopping-list product can now be marked as recurring (Daily/Weekly/Monthly, reusing the exact same TodoRecurrenceRule enum todos already use). Checking off a recurring product schedules its own reappearance date (anchored on the day-of-month the rule was first set, computed with the same RecurrenceCalculator todos use); a new daily sweep (RollForwardRecurringShoppingProductsCommandHandler, bundled into the existing DueNotificationJob) reactivates it once that date arrives, preserving its last-used quantity. A normal, non-recurring product behaves exactly as before (purely additive, per the AC).

Design decisions:

Deliberately simpler than the todo recurrence mechanism: todos are due-date-anchored and spawn a brand-new row on completion; shopping products are permanent rows with no due date, so recurrence here is a single stored next-reappearance date set once at checkoff time and consumed once at reactivation - no due-date requirement, no rotate-assignee concept (shopping products have neither).
ActivatedVia gained a new RecurrenceAuto discriminator (alongside the existing Manual/PantryAuto/RecipeApp) so the sweep-triggered reactivation is distinguishable from a manual re-add, same one-shared-source-model pattern the field already followed.
ShoppingProductDto.RecurrenceRule follows the exact same not-a-primary-constructor-parameter pattern already established for CommentCount/Labels on the same DTO (only the list query and the Set command populate it, other mutation handlers return it unset) - a known, accepted gap, not something this story introduces.

Tests: 15 new/extended backend handler tests across Deactivate/Activate/SetRecurrence/RollForward (including a fan-out-preserves-quantity case and a defensive never-reactivates-an-already-active-row case) plus a new ShoppingProductRecurrencePicker component test suite and extended ShoppingProductItem coverage for the repeat badge/menu. Full backend suite (1106 tests) and frontend suite (1321 tests) green after the change.

Migration: 20260911203321_AddShoppingProductRecurrence (RecurrenceRule/RecurrenceAnchorDay/RecurrenceNextDate columns on ShoppingProductEntity, all nullable, purely additive).

Implemented and merged (c2511a3e). **Scope:** a shopping-list product can now be marked as recurring (Daily/Weekly/Monthly, reusing the exact same TodoRecurrenceRule enum todos already use). Checking off a recurring product schedules its own reappearance date (anchored on the day-of-month the rule was first set, computed with the same RecurrenceCalculator todos use); a new daily sweep (RollForwardRecurringShoppingProductsCommandHandler, bundled into the existing DueNotificationJob) reactivates it once that date arrives, preserving its last-used quantity. A normal, non-recurring product behaves exactly as before (purely additive, per the AC). **Design decisions:** - Deliberately simpler than the todo recurrence mechanism: todos are due-date-anchored and spawn a brand-new row on completion; shopping products are permanent rows with no due date, so recurrence here is a single stored next-reappearance date set once at checkoff time and consumed once at reactivation - no due-date requirement, no rotate-assignee concept (shopping products have neither). - ActivatedVia gained a new RecurrenceAuto discriminator (alongside the existing Manual/PantryAuto/RecipeApp) so the sweep-triggered reactivation is distinguishable from a manual re-add, same one-shared-source-model pattern the field already followed. - ShoppingProductDto.RecurrenceRule follows the exact same not-a-primary-constructor-parameter pattern already established for CommentCount/Labels on the same DTO (only the list query and the Set command populate it, other mutation handlers return it unset) - a known, accepted gap, not something this story introduces. **Tests:** 15 new/extended backend handler tests across Deactivate/Activate/SetRecurrence/RollForward (including a fan-out-preserves-quantity case and a defensive never-reactivates-an-already-active-row case) plus a new ShoppingProductRecurrencePicker component test suite and extended ShoppingProductItem coverage for the repeat badge/menu. Full backend suite (1106 tests) and frontend suite (1321 tests) green after the change. **Migration:** 20260911203321_AddShoppingProductRecurrence (RecurrenceRule/RecurrenceAnchorDay/RecurrenceNextDate columns on ShoppingProductEntity, all nullable, purely additive).

lena closed this issue

2026-09-11 22:58:37 +02:00

Rows
Columns

Wiederkehrende Eintraege auf der Einkaufsliste (feste Turnusartikel) #183

Story: Wiederkehrende Eintraege auf der Einkaufsliste (feste Turnusartikel)