[TAN-7698] Blocked words in items do not prevent admins from making unrelated edits

[jinjagit]

The fix

• BlockingProfanity#verify_profanity now scans only attributes that this request actually changed (via ActiveModel::Dirty), and for *_multiloc attributes only the locales whose value differs from the previously-persisted one.
• Resolves the case where admins were blocked from benign updates — e.g. an idea status change — purely because the stored body contained a word that is, or has since become, on the blocklist.
• Adds acceptance coverage in ideas_update_spec.rb and comments_spec.rb; existing create-time and extended_blocking user-update coverage still passes.

Not covered

• Bug 2 — silent failure in the admin UI. useUpdateIdea and its admin callers don't pattern-match error: 'includes_banned_words', so when the check legitimately should fire (e.g. an admin edits a body and introduces a flagged word) the 422 is swallowed and no message is shown. Maybe worth a follow-up.
• Historic data with flagged stored content. This PR stops re-validation from blocking unrelated updates, but doesn't surface or clean up records whose stored content contains blocklist hits. No admin-side audit of past blocks exists.
• Creation paths that bypass the concern entirely (bulk import, seeds, rake tasks, machine-translation writes). Out of scope here — orthogonal to the re-validation defect.

Changelog

Fixed

• [TAN-7698] Blocked words in items do not prevent admins from making unrelated edits (e.g. changing idea status)

[notion-workspace]

🐛 Forbidden words block admins from working

[cl-dev-bot]

	Messages
📖	Changelog provided 🎉
📖	Notion issue: TAN-7698
📖	Run the e2e tests
📖	Check translation progress

Generated by 🚫 dangerJS against 08e07a8

[jamesspeake]

Looks a good solution to me