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 einem zugewiesenen Todo #163

New issue
Closed
opened 2026-09-06 19:55:39 +02:00 by lena · 2 comments
lena commented 2026-09-06 19:55:39 +02:00
Collaborator
Copy link

Story: Benachrichtigung bei neuem Kommentar auf einem zugewiesenen Todo

As a Mitglied, dem ein Todo zugewiesen ist,
I want to benachrichtigt werden, wenn jemand einen Kommentar dazu schreibt,
so that ich Nachrichten fuer mich nicht verpasse, ohne jedes Todo einzeln erneut oeffnen zu muessen.

Background

CreateCommentCommandHandler.cs hat aktuell keinerlei Anbindung an die bestehende Notification-Pipeline (In-App-Glocke, Push, E-Mail, Digest) - ein Kommentar auf einem Todo bleibt fuer den Assignee vollstaendig unbemerkt, bis er das Todo zufaellig erneut oeffnet. Die Infrastruktur dafuer (NotificationEntity, CreateNotificationCommand, NotificationKind-Enum, Push/E-Mail-Zustellung) existiert bereits vollstaendig und wird fuer aehnliche Faelle (z. B. TodoAssigned, AddedToList) schon genutzt.

Acceptance criteria:

  • Wird ein Kommentar auf einem Todo erstellt, das einen Assignee hat, erhaelt dieser Assignee eine Benachrichtigung (In-App-Glocke, plus Push/E-Mail gemaess seinen bestehenden Benachrichtigungseinstellungen) - ausser der Assignee ist selbst der Autor des Kommentars.
  • Der Benachrichtigungstext folgt dem bestehenden Muster (z. B. "X commented on 'Todo-Titel'").
  • Nutzt die bestehende CreateNotificationCommand/NotificationKind-Infrastruktur statt eines neuen Zustellwegs.

Out of scope for this story:

  • Kommentare auf Vorratsschrank-Produkten oder Masterpacklisten-Eintraegen (dort gibt es kein Assignee-Konzept) - moegliche eigene Folge-Story.
  • @Erwaehnungen anderer Mitglieder im Kommentartext.
  • Benachrichtigung des Listen-Owners oder anderer Mitglieder, die nicht der Assignee sind.

Open questions: (escalate to human if unanswered)

  • Keine - klar umrissene, kleine Ergaenzung an eine bereits bestehende Pipeline.
## Story: Benachrichtigung bei neuem Kommentar auf einem zugewiesenen Todo **As a** Mitglied, dem ein Todo zugewiesen ist, **I want to** benachrichtigt werden, wenn jemand einen Kommentar dazu schreibt, **so that** ich Nachrichten fuer mich nicht verpasse, ohne jedes Todo einzeln erneut oeffnen zu muessen. ## Background `CreateCommentCommandHandler.cs` hat aktuell keinerlei Anbindung an die bestehende Notification-Pipeline (In-App-Glocke, Push, E-Mail, Digest) - ein Kommentar auf einem Todo bleibt fuer den Assignee vollstaendig unbemerkt, bis er das Todo zufaellig erneut oeffnet. Die Infrastruktur dafuer (`NotificationEntity`, `CreateNotificationCommand`, `NotificationKind`-Enum, Push/E-Mail-Zustellung) existiert bereits vollstaendig und wird fuer aehnliche Faelle (z. B. `TodoAssigned`, `AddedToList`) schon genutzt. **Acceptance criteria:** - [ ] Wird ein Kommentar auf einem Todo erstellt, das einen Assignee hat, erhaelt dieser Assignee eine Benachrichtigung (In-App-Glocke, plus Push/E-Mail gemaess seinen bestehenden Benachrichtigungseinstellungen) - ausser der Assignee ist selbst der Autor des Kommentars. - [ ] Der Benachrichtigungstext folgt dem bestehenden Muster (z. B. "X commented on 'Todo-Titel'"). - [ ] Nutzt die bestehende `CreateNotificationCommand`/`NotificationKind`-Infrastruktur statt eines neuen Zustellwegs. **Out of scope for this story:** - Kommentare auf Vorratsschrank-Produkten oder Masterpacklisten-Eintraegen (dort gibt es kein Assignee-Konzept) - moegliche eigene Folge-Story. - @Erwaehnungen anderer Mitglieder im Kommentartext. - Benachrichtigung des Listen-Owners oder anderer Mitglieder, die nicht der Assignee sind. **Open questions:** (escalate to human if unanswered) - Keine - klar umrissene, kleine Ergaenzung an eine bereits bestehende Pipeline.
lena self-assigned this 2026-09-06 20:39:11 +02:00
lena commented 2026-09-06 20:39:35 +02:00
Author
Collaborator
Copy link

Claiming this. Plan: add a TodoCommentCreatedNotificationDecorator-style hook (or an inline call, matching whichever pattern CreateTodoCommandHandler's existing TodoAssigned/AddedToList notification call sites use) inside CreateCommentCommandHandler that, after a comment is persisted, checks the todo's AssigneeId: if set and not equal to the comment's author, fires CreateNotificationCommand with a new NotificationKind.TodoCommented (or equivalent existing-pattern name) carrying the todo's title, mirroring the existing "X commented on 'Todo-Titel'" text convention. Will reuse the existing Push/E-Mail dispatch path already wired to CreateNotificationCommand - no new delivery mechanism. No open questions on the issue itself, so proceeding directly to implementation.

Claiming this. Plan: add a `TodoCommentCreatedNotificationDecorator`-style hook (or an inline call, matching whichever pattern `CreateTodoCommandHandler`'s existing `TodoAssigned`/`AddedToList` notification call sites use) inside `CreateCommentCommandHandler` that, after a comment is persisted, checks the todo's `AssigneeId`: if set and not equal to the comment's author, fires `CreateNotificationCommand` with a new `NotificationKind.TodoCommented` (or equivalent existing-pattern name) carrying the todo's title, mirroring the existing "X commented on 'Todo-Titel'" text convention. Will reuse the existing Push/E-Mail dispatch path already wired to `CreateNotificationCommand` - no new delivery mechanism. No open questions on the issue itself, so proceeding directly to implementation.
lena commented 2026-09-06 20:52:03 +02:00
Author
Collaborator
Copy link

Implemented and merged in commit 0888176 on master.

Scope: CreateCommentCommandHandler now fires a NotificationKind.TodoCommented notification for a todo's assignee whenever a new comment is added, unless the assignee is the comment's own author. Mirrors AssignTodoCommandHandler's existing notification-trigger pattern exactly: body text is "{authorDisplayName} commented on '{title}'", delivered via the existing CreateNotificationCommand/NotificationKind infrastructure (no new delivery path) - push and in-app WS delivery are already generic across all notification kinds, and email stays unchanged (only TodoDueToday/TodoOverdue get instant email, matching TodoAssigned's own existing scope - not extended here per AC bullet 3).

Out of scope, as specified: Pantry/MasterPacking comments (no assignee concept there), @mentions, and notifying non-assignee members - none implemented.

Tests: 3 new backend unit tests (notifies a different assignee, suppresses when the assignee is the comment's own author, suppresses when there's no assignee) - all confirmed to reach the expected DockerUnavailableException in this sandbox (no Docker available), proving DI wiring is correct.

Verification: dotnet build clean; full frontend suite green (125 files/1175 tests, unchanged - the only frontend change is an additive TS union member for the new notification kind, which needs no new UI logic since NotificationItem.tsx renders body/kind generically); tsc -b/npm run build clean. A dedicated security-review pass found no IDOR (recipient is derived server-side from the todo's own current assignee, never client input) or injection issues (body is plain-text, rendered as a JSX text child, and only exposes information already visible to any list member via the todo's own comment list).

Closing as done.

Implemented and merged in commit 0888176 on master. **Scope:** `CreateCommentCommandHandler` now fires a `NotificationKind.TodoCommented` notification for a todo's assignee whenever a new comment is added, unless the assignee is the comment's own author. Mirrors `AssignTodoCommandHandler`'s existing notification-trigger pattern exactly: body text is `"{authorDisplayName} commented on '{title}'"`, delivered via the existing `CreateNotificationCommand`/`NotificationKind` infrastructure (no new delivery path) - push and in-app WS delivery are already generic across all notification kinds, and email stays unchanged (only `TodoDueToday`/`TodoOverdue` get instant email, matching `TodoAssigned`'s own existing scope - not extended here per AC bullet 3). **Out of scope, as specified:** Pantry/MasterPacking comments (no assignee concept there), @mentions, and notifying non-assignee members - none implemented. **Tests:** 3 new backend unit tests (notifies a different assignee, suppresses when the assignee is the comment's own author, suppresses when there's no assignee) - all confirmed to reach the expected `DockerUnavailableException` in this sandbox (no Docker available), proving DI wiring is correct. **Verification:** `dotnet build` clean; full frontend suite green (125 files/1175 tests, unchanged - the only frontend change is an additive TS union member for the new notification kind, which needs no new UI logic since `NotificationItem.tsx` renders `body`/`kind` generically); `tsc -b`/`npm run build` clean. A dedicated security-review pass found no IDOR (recipient is derived server-side from the todo's own current assignee, never client input) or injection issues (body is plain-text, rendered as a JSX text child, and only exposes information already visible to any list member via the todo's own comment list). Closing as done.
lena closed this issue 2026-09-06 20:52:09 +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#163
No description provided.