Filament Mail Log Laravel Package

Product Decisions This Supports

• Build vs. buy for internal mail tooling. The package has crossed a line worth naming: it is no longer just a read-only mail log with a Filament preview, it is now a sending surface. v1.1.0 adds a Resend action that re-mails the stored copy to the same or different recipients, with optional Cc/Bcc. That absorbs the recurring "can we just re-send the verification e-mail?" ask from support — but it also means the build-vs-buy comparison is now against workflow tooling (an ops console), not just a log viewer. Decide once whether support-initiated resends belong in your admin panel or in your ESP's UI; splitting the two creates two audit trails.
• Threat model for the admin panel. A panel user can now cause outbound e-mail to arbitrary validated addresses, including Cc/Bcc. That is a spam/abuse vector and an impersonation surface ("resend this password reset to [email protected]"). The package gives you the right primitive — a separate resendMailLog gate / MailLogPlugin::authorizeResend(), closed by default — but the product decision is yours: who holds that permission, is it a distinct role from "view mail log", and do you require a ticket reference or second approval for high-risk templates (password reset, magic links)?
• Privacy-by-design and retention policy. Unchanged from v1.0.1 and still the sharpest lever: redaction is prefix-based and redacts every segment after a configured prefix, while intentionally keeping ?email= on reset links as personal data rather than a secret. New wrinkle: v1.1.0's confirmation modal explicitly warns when secrets were stripped from the stored copy (signed links will be broken) or the body was truncated. That warning is a symptom of a policy choice — if your redaction patterns are aggressive, resend becomes unreliable for exactly the highest-value templates. Ratify the policy, then decide whether resend should be disabled for redacted rows.
• Support/CS workflow — roadmap item partially delivered. The previous assessment listed self-service resend and per-user delivery history as roadmap input. v1.1.0 ships the agent-side resend and the beginning of lineage: each resend is a new row linked via resent_from_id, with "Resent from #id" / "Resent N times" on the message page. What remains open is customer-facing self-service and a true per-user delivery timeline. Treat this as evidence the maintainer ships workflow features, not just fixes.
• Deliverability and suppression integrity. Two gaps to decide on deliberately: (1) resend.mailer lets you route resends through a different transport, so you must choose whether resends should be visible to your ESP's analytics/suppression logic or deliberately isolated from it; (2) the package does not check suppression — a resend to a hard-bounced address is possible. Also note the modal states attachments are not resent (only names are stored), so "resend the invoice" will arrive without the invoice. Both are support-script requirements, not code defects.
• Vendor risk and upgrade cadence. v1.0.1 remains a security-relevant patch (previously /email/verify/[REDACTED]/{hash} left the secret hash visible while hiding the harmless id) — any deployment on an earlier tag is still a mandatory upgrade. v1.1.0 raises the operational bar in a good way: the resend action is hidden until the add_resent_from_id_to_mail_logs_table migration is published and run, and logging degrades gracefully to prior behavior. That is a mature rollout pattern and a reason to trust the release process, but it means your deploy runbook must include the migration or the feature silently won't exist.
• Scope discipline / maturity signals. v1.0.1 fixed the preview iframe rendering at 300px on a stock panel (Tailwind classes Filament doesn't ship, replaced with inline styles, light and dark) and shipped a workbench demo. v1.1.0 adds English and Ukrainian translations, address validation, and a confirmation modal — small but consistent signals that the maintainer tests against a stock panel rather than a bespoke setup, and is optimizing for real operator mistakes.

When to Consider This Package

Adopt when:

• You run a Laravel app with a Filament admin panel and need support/QA visibility into outbound transactional e-mail.
• You store or display links containing secrets (signed URLs, verification hashes, reset tokens) and need a defensible masking guarantee.
• New: support or QA regularly re-sends transactional mail by hand today (copy-paste from the ESP, or "engineering, please resend"), and you want that action logged, permissioned, and attributable to the original message.
• You can run the required migration in your deploy pipeline, and you are willing to gate resend behind a permission distinct from viewing.
• You are on v1.1.0 or later — or at minimum v1.0.1, since earlier versions leak the verification hash, which alone disqualifies them for production.
• You want a small, single-purpose dependency rather than a full mail-analytics platform.

Look elsewhere when:

• You are not on Filament, or the preview is the only feature you actually want.
• You need delivery analytics, bounce handling, suppression-list enforcement, or open/click tracking — that is your transactional provider's job (SES/Postmark/Mailgun webhooks), not this package's. Resend does not change that; it does not check bounces.
• Your data policy forbids storing message bodies or recipient addresses at all; redaction reduces but does not eliminate the PII footprint, since ?email= is retained by default.
• Your compliance posture requires approval workflows, dual control, or immutable external audit logs for outbound mail — the "Resent N times" lineage is useful but it lives in the same mutable database table.
• You need attachments actually re-delivered, or you require data residency / per-tenant isolation guarantees the package does not document.

How to Pitch It (Stakeholders)

For executives: A small, focused dependency that gives support staff a safe view of the e-mails we send customers — and, as of v1.1.0, the ability to re-send them without escalating to engineering. That closes a recurring time-to-resolution gap on login and verification tickets and gives us a written record of who re-sent what, to whom, and from which original message. It is privacy-conscious by design (secrets masked in stored links) and the new send capability is off by default behind its own permission. The 1.0.1 security patch fixed a genuine leak where verification hashes could stay readable in the admin panel, so anyone already running an earlier version should upgrade now; for new adopters this remains a low-risk, single-purpose dependency.

For engineering: Drop-in for Laravel + Filament. Upgrade path matters: publish and run add_resent_from_id_to_mail_logs_table — until then the resend action is simply hidden and logging behaves as before, so the migration is a feature gate, not a breaking change. The Resend action is closed by default behind resendMailLog / MailLogPlugin::authorizeResend(), separate from the view permission; wire it into a distinct role. Config: resend.enabled, resend.mailer (choose deliberately — routing resends through a different transport changes your ESP analytics and suppression behavior), resend.queue (async sends — monitor the queue). Known limits to document in the support runbook: the modal warns when redaction or truncation has broken signed links, attachments are never resent (only names stored), and there is no bounce/suppression check. The v1.0.1 preview-iframe fix (Tailwind classes Filament doesn't ship → inline styles, light and dark) and corrected prefix redaction (all trailing segments, not just the first) still apply; ?email= on reset links remains intentionally retained as personal data — add a redaction.patterns entry if policy says otherwise. Gate the panel behind authorization and pin the version.