Warning: This build has drifted.
The coverage report for this pull request build may be inaccurate because its base commit is no longer the HEAD of its target branch.
This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

    • Learn more: For more information on this, see Tracking coverage changes for pull request builds.
    • Fix now: For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
    • Prevent going forward: To avoid this issue with future PRs, see these Recommended CI Configurations.

Announce edited comments the way new ones are announced

notifyService.Submit was called only from createCommentCtrl, so an edit reached no destination at all. Since admin copies ride inside the same Request that carries user notifications (AdminEmails in email.go, AdminChannelID in telegram.go), that left a gap an ordinary user could walk through: post something innocuous, let it clear the admin notification channels, then swap the text with a PUT inside the five-minute edit window and have nothing emitted anywhere. Editing needs no privileges beyond owning the comment, so the sequence was available to anyone who could post.

updateCommentCtrl now submits the edited comment. The value returned by EditComment is already sanitized and carries Locator, ParentID and the edit mark, so Submit resolves ancestor recipients exactly as it does on create, and destinations render the new text.

A delete is deliberately not announced. It already emits admin.EvDelete from the service, and mailing the removed text out to every ancestor and admin channel would defeat the removal.

The tradeoff is that thread ancestors now get a second notification for any edit, typo fixes included. The alternative, routing edits to the admin destinations only, needs a new field on notify.Request plus template changes across all four destinations, and is left for later.