1.21.0 — Confirmation pages, honest email sends, and commit-safe job publishing

2026-08-28

django-mojo 1.21.0 makes emailed account links safe to open — verification, email-change and deactivation links now land on a confirmation page and change nothing until the person presses the button — makes email endpoints report send failures honestly instead of claiming success, publishes background jobs to workers only after the writing transaction commits, and records sign-ins and browser sign-outs in the account security history. Minor because the confirmation-link behavior change requires consumer attention before upgrading.

Breaking

• Opening an email verification or email-change confirmation link no longer applies the change. The confirmation GET routes render a page; the change is committed only by an explicit button press. Integrations that relied on the GET committing must switch to the confirm endpoints.
• Emailed verification, email-change and deactivation links are now built from the platform's BASE_URL and point at the API's own confirmation pages. A deployment without BASE_URL set emails root-relative links that a mail client cannot open.

Added

• Human confirmation pages for email verification, email change and account deactivation — safe to scan, preview or prefetch; the single-use token is only consumed on the button press. Legacy /auth?flow=… links redirect to them automatically.
• Confirm-only endpoints for email verification and email change: they apply the change and return the address, without signing the browser in. The existing token-returning endpoints keep their contract for app clients.
• Successful sign-ins now appear in the account's security history, and a new audit-only sign-out endpoint lets a browser record that it signed out. It revokes nothing on other devices, and the docs say so plainly.
• Brand-scoped security history: with a brand selected, the feed shows only that brand's own activity plus account-wide email-change entries — never another brand's rows.
• Rate limiters can omit request details from their throttle diagnostics; the confirmation pages use this so a throttled request never records its own token.

Changed

• Background jobs published inside a database transaction become visible to workers only after that transaction commits; a rolled-back transaction publishes nothing.
• A Redis error while queueing no longer marks the job failed. The job stays runnable, carries a "Redis publish not confirmed" marker, and files one budgeted operator incident. After such an error, retry only with the same idempotency key — a blind re-publish can run the work twice.
• "Sent" now means the provider accepted the message. Verification resend and email-change requests return a retryable failure (HTTP 503, fixed copy) when the provider did not accept — a deployment with no sending mailbox configured now sees 503s where it previously saw silent success.
• Email-change request and failure history entries are recorded directly and no longer pass through incident rule sets or event metrics; an operator rule matching them stops firing.

Fixed

• A worker could receive a job notification before the job row was committed and permanently discard the work, leaving the caller stuck.
• The signed-in verification resend endpoint reported success when no mailbox was configured or the provider refused the message.
• Email-change requests recorded "requested" history even when the confirmation email was never accepted for delivery.

Security

• Clicking an email-change confirmation link no longer delivers sign-in tokens to the browser that opened it; the confirmation page uses a commit-only endpoint.
• The confirmation pages send no referrer, deny framing, keep the token out of executable page content and browser storage, and scrub it from the address bar. Emailed link origins are never derived from the request's Host header.

Upgrade notes

• Set BASE_URL before upgrading if it is unset — readiness reports it, and emailed account links now depend on it.
• The two old confirmation templates were replaced by new landing templates. A deployment override of an old template name is silently never rendered again; move the override to the landing templates.
• Existing email-template rows in the database are not modified; only absent templates are seeded. Update your rows if you want the new "you will be asked to confirm on the page that opens" wording.
• Job monitors that keyed on a failed status for publish errors should watch the "Redis publish not confirmed" marker and the new operator incident instead — publish errors no longer produce failed jobs.
• Sign-in rows in the security feed carry a brand only when the sign-in request itself carried that brand; send your group context on login if you want sign-ins visible in brand-scoped views.