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

Benachrichtigung bei neuem Kommentar auf Einkaufslisten-/Vorratsschrank-/Masterpack-Produkten #185

New issue
Closed
opened 2026-09-10 21:42:11 +02:00 by lena · 2 comments
lena commented 2026-09-10 21:42:11 +02:00
Collaborator
Copy link

Story: Benachrichtigung bei neuem Kommentar auf Einkaufslisten-/Vorratsschrank-/Masterpack-Produkten

As a Mitglied, das zuvor selbst auf einem Einkaufslisten-, Vorratsschrank- oder Masterpackprodukt kommentiert hat,
I want to benachrichtigt zu werden, wenn danach jemand anderes auf demselben Produkt/Item kommentiert,
so that ich eine Diskussion (z. B. "welche Marke genau?", "brauchen wir das wirklich?") nicht verpasse, ohne die Liste staendig manuell zu pruefen.

Kontext (verifiziert im Code): Kommentare existieren bereits auf Einkaufslisten-Produkten (#179), Vorratsschrank-Produkten (#101c) und Masterpack-Items (bereits im urspruenglichen #101/#93-Umfang). Fuer Todos gibt es bereits eine Kommentar-Benachrichtigung (#163, CreateCommentCommandHandler.cs, NotificationKind.TodoCommented) - die aber am Todo-Assignee haengt, den es fuer Einkaufslisten-/Vorratsschrank-/Masterpack-Produkte nicht gibt (dort gibt es keine Einzel-Zuweisung, nur Listen-Mitgliedschaft).

Design-Entscheidung (aufgeloest, kein Eskalationsbedarf): Da es kein Assignee-Aequivalent gibt, benachrichtigt diese Story stattdessen alle bisherigen Kommentatoren desselben Produkts/Items (auszer dem Autor des neuen Kommentars) - dasselbe "Teilnehmer eines Threads" Muster, das z. B. GitHub Issue-Kommentare verwenden. Kein Benachrichtigen aller Listenmitglieder pauschal (das waere zu viel Rauschen fuer Listen mit vielen Mitgliedern und passt nicht zum bestehenden Opt-in-artigen Charakter von #163).

Acceptance criteria:

  • Neue NotificationKind-Werte fuer Shopping-/Pantry-/MasterPack-Produktkommentare (analog zu TodoCommented).
  • Wenn ein neuer Kommentar auf einem Produkt/Item erstellt wird, werden alle fruheren Kommentatoren desselben Produkts/Items (auszer dem Autor des neuen Kommentars) per In-App-Benachrichtigung informiert - Zustellung ueber die bestehende CreateNotificationCommand-Infrastruktur, kein neuer Versandweg.
  • Folgt der bestehenden Email/Push-Digest-Pipeline automatisch (keine Sonderbehandlung noetig, da diese generisch ueber den Notification-Stream laeuft).
  • Der allererste Kommentar auf einem Produkt/Item loest naturgemaess keine Benachrichtigung aus (es gibt noch keine fruheren Kommentatoren).

Out of scope for this story:

  • Benachrichtigung aller Listenmitglieder (nur bisherige Kommentatoren, siehe Design-Entscheidung oben).
  • Rueckwirkende Aenderung des Todo-Kommentar-Verhaltens (#163 bleibt Assignee-basiert, unveraendert).

Open questions: (escalate to human if unanswered)

  • Keine - Design-Entscheidung oben aufgeloest, ueberträgt ein bereits bewaehrtes Benachrichtigungs-Infrastruktur-Muster auf drei weitere Produkt-/Item-Typen.
## Story: Benachrichtigung bei neuem Kommentar auf Einkaufslisten-/Vorratsschrank-/Masterpack-Produkten **As a** Mitglied, das zuvor selbst auf einem Einkaufslisten-, Vorratsschrank- oder Masterpackprodukt kommentiert hat, **I want to** benachrichtigt zu werden, wenn danach jemand anderes auf demselben Produkt/Item kommentiert, **so that** ich eine Diskussion (z. B. "welche Marke genau?", "brauchen wir das wirklich?") nicht verpasse, ohne die Liste staendig manuell zu pruefen. **Kontext (verifiziert im Code):** Kommentare existieren bereits auf Einkaufslisten-Produkten (#179), Vorratsschrank-Produkten (#101c) und Masterpack-Items (bereits im urspruenglichen #101/#93-Umfang). Fuer Todos gibt es bereits eine Kommentar-Benachrichtigung (#163, `CreateCommentCommandHandler.cs`, `NotificationKind.TodoCommented`) - die aber am Todo-`Assignee` haengt, den es fuer Einkaufslisten-/Vorratsschrank-/Masterpack-Produkte nicht gibt (dort gibt es keine Einzel-Zuweisung, nur Listen-Mitgliedschaft). **Design-Entscheidung (aufgeloest, kein Eskalationsbedarf):** Da es kein Assignee-Aequivalent gibt, benachrichtigt diese Story stattdessen alle *bisherigen Kommentatoren* desselben Produkts/Items (auszer dem Autor des neuen Kommentars) - dasselbe "Teilnehmer eines Threads" Muster, das z. B. GitHub Issue-Kommentare verwenden. Kein Benachrichtigen aller Listenmitglieder pauschal (das waere zu viel Rauschen fuer Listen mit vielen Mitgliedern und passt nicht zum bestehenden Opt-in-artigen Charakter von #163). **Acceptance criteria:** - [ ] Neue `NotificationKind`-Werte fuer Shopping-/Pantry-/MasterPack-Produktkommentare (analog zu `TodoCommented`). - [ ] Wenn ein neuer Kommentar auf einem Produkt/Item erstellt wird, werden alle fruheren Kommentatoren desselben Produkts/Items (auszer dem Autor des neuen Kommentars) per In-App-Benachrichtigung informiert - Zustellung ueber die bestehende `CreateNotificationCommand`-Infrastruktur, kein neuer Versandweg. - [ ] Folgt der bestehenden Email/Push-Digest-Pipeline automatisch (keine Sonderbehandlung noetig, da diese generisch ueber den Notification-Stream laeuft). - [ ] Der allererste Kommentar auf einem Produkt/Item loest naturgemaess keine Benachrichtigung aus (es gibt noch keine fruheren Kommentatoren). **Out of scope for this story:** - Benachrichtigung aller Listenmitglieder (nur bisherige Kommentatoren, siehe Design-Entscheidung oben). - Rueckwirkende Aenderung des Todo-Kommentar-Verhaltens (#163 bleibt Assignee-basiert, unveraendert). **Open questions:** (escalate to human if unanswered) - Keine - Design-Entscheidung oben aufgeloest, ueberträgt ein bereits bewaehrtes Benachrichtigungs-Infrastruktur-Muster auf drei weitere Produkt-/Item-Typen.
lena self-assigned this 2026-09-11 22:47:49 +02:00
lena commented 2026-09-11 22:48:01 +02:00
Author
Collaborator
Copy link

Claiming this. Plan (resolves a structural question the design note above did not anticipate): NotificationEntity's target was already generalized from a hard Todo-only FK to a two-way Todo/Pantry nullable-FK model by #186. Extending that same generalization to a 4-way exactly-one-of (Todo/Pantry/Shopping/MasterPacking), rather than inventing a separate notification path, so ShoppingProductCommented/PantryProductCommented/MasterPackItemCommented reuse the existing NotificationDto/WS-publish/notification-panel infrastructure end to end. Each of the three CreateXCommentCommandHandlers gets a small NotifyPriorCommentersAsync step after inserting the new comment: query distinct prior commenters on that product/item (excluding the current author), insert one notification per recipient targeting the owning list, publish via the existing notificationSubject. No idempotency index needed (unlike #186's recurring sweep) since this is a one-shot event per comment, not a sweep.

Claiming this. Plan (resolves a structural question the design note above did not anticipate): `NotificationEntity`'s target was already generalized from a hard Todo-only FK to a two-way Todo/Pantry nullable-FK model by #186. Extending that same generalization to a 4-way exactly-one-of (Todo/Pantry/Shopping/MasterPacking), rather than inventing a separate notification path, so `ShoppingProductCommented`/`PantryProductCommented`/`MasterPackItemCommented` reuse the existing `NotificationDto`/WS-publish/notification-panel infrastructure end to end. Each of the three CreateXCommentCommandHandlers gets a small NotifyPriorCommentersAsync step after inserting the new comment: query distinct prior commenters on that product/item (excluding the current author), insert one notification per recipient targeting the owning list, publish via the existing notificationSubject. No idempotency index needed (unlike #186's recurring sweep) since this is a one-shot event per comment, not a sweep.
lena commented 2026-09-11 23:22:10 +02:00
Author
Collaborator
Copy link

Implemented and merged (commits c086a729, 8b90bc64).

Scope: Notifies a user when someone else comments on a Shopping-list product, Pantry product, or Master Packing item they previously commented on themselves - a "thread participants" model, since these list types have no per-item assignee unlike Todos (#163's TodoCommented).

Backend:

  • NotificationEntity's target FK, already generalized Todo→Todo/Pantry by #186, widened to a 4-way Todo/Pantry/Shopping/MasterPacking model (nullable FK columns + widened CK_NotificationEntity_ExactlyOneTarget check constraint).
  • 3 new NotificationKind values: ShoppingProductCommented, PantryProductCommented, MasterPackItemCommented.
  • Each of the three comment-creation handlers now queries for distinct prior commenters on that product/item (excluding the new comment's own author) and inserts one notification per recipient.
  • NotificationDto/notification query+command handlers extended with the two new target id/title pairs.

Frontend: NotificationItem navigation and title-line rendering extended to cover the two new target types.

Tests: 15 new backend tests across the three comment-handler test files (notify-on-comment, no-self-notify, no-notify-on-first-comment) plus a new CreateMasterPackItemCommentCommandHandlerTests.cs file; frontend fixtures/tests extended for the new DTO fields and navigation cases. Full suite green: 1117 backend tests (946+52+119), 1324 frontend tests (136 files).

Key decision: reused the existing notificationSubject/manual NotificationEntity construction pattern (as #186's Pantry-due-notification handlers already do) rather than the shared CreateNotificationCommand, since that command is still hard-tied to TodoListId only and wasn't in scope to generalize here.

Implemented and merged (commits c086a729, 8b90bc64). **Scope:** Notifies a user when someone else comments on a Shopping-list product, Pantry product, or Master Packing item they previously commented on themselves - a "thread participants" model, since these list types have no per-item assignee unlike Todos (#163's TodoCommented). **Backend:** - `NotificationEntity`'s target FK, already generalized Todo→Todo/Pantry by #186, widened to a 4-way Todo/Pantry/Shopping/MasterPacking model (nullable FK columns + widened `CK_NotificationEntity_ExactlyOneTarget` check constraint). - 3 new `NotificationKind` values: `ShoppingProductCommented`, `PantryProductCommented`, `MasterPackItemCommented`. - Each of the three comment-creation handlers now queries for distinct prior commenters on that product/item (excluding the new comment's own author) and inserts one notification per recipient. - `NotificationDto`/notification query+command handlers extended with the two new target id/title pairs. **Frontend:** `NotificationItem` navigation and title-line rendering extended to cover the two new target types. **Tests:** 15 new backend tests across the three comment-handler test files (notify-on-comment, no-self-notify, no-notify-on-first-comment) plus a new `CreateMasterPackItemCommentCommandHandlerTests.cs` file; frontend fixtures/tests extended for the new DTO fields and navigation cases. Full suite green: 1117 backend tests (946+52+119), 1324 frontend tests (136 files). **Key decision:** reused the existing `notificationSubject`/manual `NotificationEntity` construction pattern (as #186's Pantry-due-notification handlers already do) rather than the shared `CreateNotificationCommand`, since that command is still hard-tied to `TodoListId` only and wasn't in scope to generalize here.
lena closed this issue 2026-09-11 23:22:14 +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#185
No description provided.