Skip to content

feat: server-wide default quarantine notification settings + modern notification template#7307

Open
discostur wants to merge 3 commits into
mailcow:stagingfrom
discostur:feat/quarantine-global-defaults
Open

feat: server-wide default quarantine notification settings + modern notification template#7307
discostur wants to merge 3 commits into
mailcow:stagingfrom
discostur:feat/quarantine-global-defaults

Conversation

@discostur

Copy link
Copy Markdown

Contribution Guidelines

What does this PR include?

Short Description

This PR adds a server-wide default for the two quarantine notification settings and modernizes the notification email template.

Until now, quarantine_notification (never / hourly / daily / weekly) and quarantine_category (rejected / junk / all) could only be configured per mailbox. New mailboxes fell back to hardcoded values in vars.inc.php, and there was no way for an admin to define a default from the UI or to push a default onto already existing mailboxes.

What's new:

  • Global default (UI): two new dropdowns in Configuration → Quarantine let an admin set the default notification interval and category for new mailboxes. They are stored in Redis (Q_DEF_NOTIFICATION, Q_DEF_CATEGORY) via the existing quarantine settings handler, exactly like the other Q_* quarantine settings.
  • New mailboxes inherit the default through a new get_quarantine_default() helper (Redis → vars.inc.php fallback). Per-mailbox user overrides keep working unchanged.
  • Apply to existing mailboxes: a new admin-only action (apply_existing, behind a confirm dialog) force-applies the current default to all existing mailboxes via JSON_SET.
  • Modernized notification email template (data/assets/templates/quarantine.tpl): clean, mobile-first responsive layout (stacked cards, tap-friendly action buttons), dark-mode aware, hidden preheader. All Jinja2 variables, HTML escaping (|e) and qhandler release/delete links are preserved. Only installs with an empty custom template (Q_HTML) are affected — existing custom templates are left untouched.

No DB schema change, no migration, no Docker image rebuild (web changes are PHP/Twig/lang; the template is a volume-mounted asset).

Affected Containers

No container needs to be rebuilt. The changed code runs in existing images:

  • php-fpm-mailcow (web UI, settings handler, mailbox defaults, language strings)
  • dovecot-mailcow (consumes the volume-mounted notification template quarantine.tpl)

Did you run tests?

What did you tested?

  • php -l on both changed PHP files (no syntax errors).
  • Rendered the rewritten quarantine.tpl with Jinja2 SandboxedEnvironment (same engine as quarantine_notify.py) for counter = 1 / many and quarantine_acl = 0 / 1: verified singular/plural text, HTML-escaped subjects, correct release vs. "send copy" wording, and that release/delete links are omitted when the recipient has no quarantine ACL.
  • Verified lang.en-gb.json stays valid JSON.
  • Manually exercised the UI flow: set defaults → save (persisted in Redis), create a new mailbox (inherits default), override on one mailbox (persists), "Apply default to all existing mailboxes" (overwrites all incl. the override).

What were the final results? (Awaited, got)

  • Awaited: new dropdowns persist; new mailboxes inherit the global default instead of the compiled-in value; user overrides still possible; force-apply rewrites all mailboxes; notification mail renders responsive on desktop and mobile with working action links.
  • Got: exactly that in all checks above.

…emplate

Add an admin-configurable, server-wide default for the quarantine
notification interval and category. Previously these two per-mailbox
settings could only fall back to compile-time values in vars.inc.php and
there was no way to set a default from the UI or apply one to existing
mailboxes.

- Store defaults in Redis (Q_DEF_NOTIFICATION, Q_DEF_CATEGORY) via the
  existing quarantine settings handler, alongside the other Q_* keys.
- New mailboxes inherit the global default through a new
  get_quarantine_default() helper (Redis -> vars.inc.php fallback).
  Per-mailbox user overrides keep working unchanged.
- New admin action "apply_existing" force-applies the default to all
  existing mailboxes (admin only, confirm dialog in the UI).
- Add two dropdowns and an apply button to the admin quarantine settings
  tab plus the corresponding language strings.
- Rewrite the notification email template (data/assets/templates/
  quarantine.tpl) as a clean, mobile-first, responsive, dark-mode aware
  layout. All Jinja2 variables, HTML escaping and qhandler links are
  preserved; only installs with an empty custom template are affected.

No DB schema change, no migration, no Docker image rebuild.
Make the default notification email look more professional and less
playful by removing the bright-green chrome:

- Header: solid green bar -> white header with dark slate title and a
  subtle bottom divider, merged flush with the body as one card.
- Primary action button (release / send copy): green -> dark slate,
  with a lighter-slate dark-mode override.

Semantic status badges (rejected = red, junk = amber) and all Jinja2
variables, escaping, qhandler links, dark-mode and mobile rules are
unchanged.
@apio-sys

Copy link
Copy Markdown

Interesting enhancement, especially for the template which could do with some modernization. What does it look like now? Would be nice to see screenshots on desktop and mobile screens.

Replace the outlined delete button with a clean filled light-grey
button (dark slate text) so it visually matches the filled "Release to
inbox" button while staying clearly secondary. Dark-mode override added.
@discostur

Copy link
Copy Markdown
Author

@apio-sys made some example screenshots, one from desktop (sogo) and one from my iphone:

Bildschirmfoto 2026-06-29 um 13 03 24 IMG_4252

@discostur

Copy link
Copy Markdown
Author

Is anyone from the maintainers going to review this?

@discostur

Copy link
Copy Markdown
Author

@milkmaker may someone from the team review this please?

@MAGICCC
MAGICCC requested a review from FreddleSpl0it July 20, 2026 09:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants