Bestehenden Kommentar auf einem Todo bearbeiten koennen #169

New issue

Closed

opened 2026-09-06 21:18:16 +02:00 by lena · 1 comment

lena commented

2026-09-06 21:18:16 +02:00

Collaborator

Story: Bestehenden Kommentar auf einem Todo bearbeiten koennen

As a Autor eines Kommentars auf einem Todo,
I want to einen bereits abgeschickten Kommentar nachtraeglich korrigieren koennen,
so that ich nicht bei jedem Tippfehler den ganzen Kommentar loeschen und neu schreiben muss (und dabei Zeitstempel/Position im Thread verliere).

Background

Checkly/Features/Comments/ hat CreateCommentCommandHandler und DeleteCommentCommandHandler, aber keinen Update-Pfad - ein Tippfehler laesst sich aktuell nur per Loeschen+Neuanlegen korrigieren, was den Kommentar ans Ende der Liste verschiebt und den urspruenglichen Zeitstempel verliert.

Acceptance criteria:

Ein neuer UpdateCommentCommand aendert den Text eines bestehenden Kommentars, nur durch dessen Autor (nicht durch andere Mitglieder oder den Listen-Owner).
Der bearbeitete Kommentar behaelt seinen CreatedAt-Zeitstempel/seine Position im Thread; optional ein „(edited)"-Hinweis in der UI.
Die Bearbeiten-Aktion ist im bestehenden Kommentar-Menue neben „Loeschen" erreichbar, nur fuer den eigenen Kommentar sichtbar (wie Loeschen es bereits ist).

Out of scope for this story:

Versionsverlauf/Aenderungshistorie des Kommentartexts.
Kommentare auf Vorratsschrank-Produkten oder Masterpacklisten-Eintraegen (eigene Entitaeten, eigene moegliche Folge-Story).

Open questions: (escalate to human if unanswered)

Keine - reine Ergaenzung eines fehlenden CRUD-Pfads neben dem bereits vorhandenen Create/Delete.

## Story: Bestehenden Kommentar auf einem Todo bearbeiten koennen **As a** Autor eines Kommentars auf einem Todo, **I want to** einen bereits abgeschickten Kommentar nachtraeglich korrigieren koennen, **so that** ich nicht bei jedem Tippfehler den ganzen Kommentar loeschen und neu schreiben muss (und dabei Zeitstempel/Position im Thread verliere). ## Background `Checkly/Features/Comments/` hat `CreateCommentCommandHandler` und `DeleteCommentCommandHandler`, aber keinen Update-Pfad - ein Tippfehler laesst sich aktuell nur per Loeschen+Neuanlegen korrigieren, was den Kommentar ans Ende der Liste verschiebt und den urspruenglichen Zeitstempel verliert. **Acceptance criteria:** - [ ] Ein neuer `UpdateCommentCommand` aendert den Text eines bestehenden Kommentars, nur durch dessen Autor (nicht durch andere Mitglieder oder den Listen-Owner). - [ ] Der bearbeitete Kommentar behaelt seinen `CreatedAt`-Zeitstempel/seine Position im Thread; optional ein „(edited)"-Hinweis in der UI. - [ ] Die Bearbeiten-Aktion ist im bestehenden Kommentar-Menue neben „Loeschen" erreichbar, nur fuer den eigenen Kommentar sichtbar (wie Loeschen es bereits ist). **Out of scope for this story:** - Versionsverlauf/Aenderungshistorie des Kommentartexts. - Kommentare auf Vorratsschrank-Produkten oder Masterpacklisten-Eintraegen (eigene Entitaeten, eigene moegliche Folge-Story). **Open questions:** (escalate to human if unanswered) - Keine - reine Ergaenzung eines fehlenden CRUD-Pfads neben dem bereits vorhandenen Create/Delete.

lena added the

priority/could

type/feature

labels

2026-09-06 21:18:16 +02:00

lena self-assigned this

2026-09-06 21:35:20 +02:00

lena added the

status/claimed

label

2026-09-06 21:35:21 +02:00

lena referenced this issue from a commit

2026-09-06 21:56:20 +02:00

feat(#169): allow editing an existing todo comment

lena referenced this issue from a commit

2026-09-06 21:56:20 +02:00

feat(#169): add comment edit UI with an "(edited)" hint

lena commented

2026-09-06 21:56:47 +02:00

Author

Collaborator

Implemented and merged in commits 64400b0d (backend) and 795bb0b5 (frontend) on master.

Scope: New UpdateCommentCommand updates a comment's Text and sets a new EditedAt timestamp; CreatedAt/thread position stay untouched, per the AC. Deliberately author-only, no owner override - a new AuthorizeCommentUpdateAccessForCurrentUserQuery was added rather than reusing the existing delete-access rule (which allows author OR list owner, for moderation) - editing someone else's words in place is a different kind of action than deleting them. Frontend adds a pencil-icon Edit button next to Delete (author-only visibility) with an inline input (Enter to save, Escape to cancel) and an "(edited)" hint next to the timestamp once a comment has been edited.

Out of scope, as specified: version history of edits; Pantry product comments or Master Packing List item comments (separate entities/DTOs, no edit feature added there).

Tests: 3 new backend handler tests (text/EditedAt update, CreatedAt/thread-position untouched, not-found) + 5 new authorization tests (author allowed; owner explicitly NOT allowed - the key behavioral difference from delete; a third member rejected; not-logged-in; comment-already-gone defers to the command's own 404) - all confirmed to reach DockerUnavailableException in this sandbox, proving DI wiring is correct. 9 new/updated frontend tests across CommentItem.test.tsx/CommentList.test.tsx (edit button visibility, inline edit flow, save/cancel, no-op on unchanged text, the edited hint).

Verification: dotnet build clean; full frontend suite green (126 files/1191 tests, +9 from this cycle); tsc -b/npm run build clean. A dedicated security-review pass specifically confirmed the update-access handler has no owner-override branch at all (not merely disabled), that the command's ExecuteUpdateAsync predicate and the authorization query's lookup use the identical (TodoListId, TodoNr, CommentId) triple from the same request (no IDOR via mismatched checks), and that the frontend's canEdit is UI-only, mirroring the already-established canDelete pattern - no findings.

Closing as done.

Implemented and merged in commits 64400b0d (backend) and 795bb0b5 (frontend) on master. **Scope:** New `UpdateCommentCommand` updates a comment's `Text` and sets a new `EditedAt` timestamp; `CreatedAt`/thread position stay untouched, per the AC. Deliberately author-only, no owner override - a new `AuthorizeCommentUpdateAccessForCurrentUserQuery` was added rather than reusing the existing delete-access rule (which allows author OR list owner, for moderation) - editing someone else's words in place is a different kind of action than deleting them. Frontend adds a pencil-icon Edit button next to Delete (author-only visibility) with an inline input (Enter to save, Escape to cancel) and an "(edited)" hint next to the timestamp once a comment has been edited. **Out of scope, as specified:** version history of edits; Pantry product comments or Master Packing List item comments (separate entities/DTOs, no edit feature added there). **Tests:** 3 new backend handler tests (text/EditedAt update, CreatedAt/thread-position untouched, not-found) + 5 new authorization tests (author allowed; **owner explicitly NOT allowed** - the key behavioral difference from delete; a third member rejected; not-logged-in; comment-already-gone defers to the command's own 404) - all confirmed to reach `DockerUnavailableException` in this sandbox, proving DI wiring is correct. 9 new/updated frontend tests across `CommentItem.test.tsx`/`CommentList.test.tsx` (edit button visibility, inline edit flow, save/cancel, no-op on unchanged text, the edited hint). **Verification:** `dotnet build` clean; full frontend suite green (126 files/1191 tests, +9 from this cycle); `tsc -b`/`npm run build` clean. A dedicated security-review pass specifically confirmed the update-access handler has no owner-override branch at all (not merely disabled), that the command's `ExecuteUpdateAsync` predicate and the authorization query's lookup use the identical `(TodoListId, TodoNr, CommentId)` triple from the same request (no IDOR via mismatched checks), and that the frontend's `canEdit` is UI-only, mirroring the already-established `canDelete` pattern - no findings. Closing as done.

lena closed this issue

2026-09-06 21:56:58 +02:00

lena referenced this issue from a commit

2026-09-06 21:58:51 +02:00

docs: record #169 cycle notes (shared-component DTO ripple, startup-project migration tip, credential-manager fallback in practice)

lena referenced this issue

2026-09-08 10:02:59 +02:00

Kommentare auf Einkaufslisten-Produkten #179