Release 1.4.0

Commentail 1.4.0 — independent email and early rule rejection

English · Русский

Stable release · 26 October 2026 · MIT.

The uploaded PyPI archives retain earlier candidate wording in the bundled README. Their package version and runtime are 1.4.0; use the upgrade commands below and the current repository/wiki documentation. Uploaded archives have not been replaced.

Changes

Configure Commentail's email independently of ordinary Django mail using the project-wide COMMENTAIL_EMAIL dictionary:

• BACKEND selects a Django email backend class.
• OPTIONS passes that backend's constructor arguments, including separate SMTP credentials or supported API-provider arguments.
• FROM_EMAIL selects the sender for every Commentail email type.

Without an override, the existing Django backend and sender remain in use. A sender-only override is supported. Nonempty options require an explicit backend. The setting belongs in Django configuration, with secrets loaded from the environment; it has no Wagtail admin fields or per-Site overrides.

The existing outbox and scheduler remain in use, including retries, leases, stable Message-ID values, access checks and original link deadlines. A provider failure does not fall back to the shared backend. Pending jobs use the active configuration when processed, including jobs queued before an update.

See the complete reference and SMTP/API examples. No provider dependency or support-matrix change is introduced.

The test_commentail_email --to recipient@example.org management command sends one test email directly through the configured Commentail backend and sender. It creates no comments or queue jobs and reports backend acceptance, which does not confirm inbox delivery. See the email reference for usage and limitations.

New guest submissions in Apply rules mode are refused immediately when an enabled Reject rule matches. The form shows that rule's optional reason and preserves the draft with and without JavaScript. No comment, confirmation mail or rejection mail is created. Existing CAPTCHA and attempt limits still apply. Review rules and soft signals retain the existing confirmation/moderation flow; registered submissions and author revisions retain their existing behavior. The lowest-ID matching Reject rule supplies the reason, with a localized default when blank. Reasons are plain text, limited to 2000 characters.

CSV export now includes reason. Legacy three-column imports remain accepted and preserve existing reasons; a present empty reason cell clears the value. Migration 0019_moderation_rule_reason adds the optional reason field with empty values for existing rules. Reversing it removes configured rule reasons.

Upgrade from 1.3.2

1. Follow your normal backup procedure, rehearse on an isolated copy, then install python -m pip install commentail==1.4.0 in your site environment.
2. Leaving COMMENTAIL_EMAIL absent preserves existing behavior. To separate mail, add the dictionary to project settings and supply its secrets to the web application and background workers.
3. Run migrate, check and your normal static collection, then restart the application and workers. Apply 0019_moderation_rule_reason; review your enabled Reject rules because matching new guest text is now refused before email proof.
4. Verify ordinary site mail still uses its shared settings. Submit a guest comment, process the outbox, confirm its email and inspect the chosen sender. Check the full notification flow with an authorized test recipient before enabling a real provider broadly.

If SMTP options are omitted, Django can still inherit the corresponding shared EMAIL_* values. Set the complete connection details required by the separate account. SMTP timeout protection remains; non-SMTP timeouts belong to the provider backend. Changing credentials does not automatically requeue failed jobs.

For upgrades from 1.3.0 or earlier, also follow the 1.3.1 irreversible migration procedure. This release does not remove the stopped-writer and matching database/key/package backup requirements.

Verification boundaries

Configuration and transport regression tests cover separate and inherited delivery, sender selection, constructor options and queue error/retry behavior. Additional coverage checks the test-mail command, early refusal, private draft recovery, reason priority, attempt limits and CSV backward compatibility. Local development backends and mocked providers establish application behavior, not real provider delivery or inbox placement. Hosted CI for the exact publishing commit, package publication and production-site acceptance are separate steps.