Filagora Logs Laravel Package

Product Decisions This Supports

• Unlocking regulated and enterprise buyers. The v0.2.2 privacy contributors turn a generic "we log every outbound email" utility into something that can answer a Data Subject Access Request (export) and a Right to Erasure request (anonymise/erase), which is table stakes for GDPR/CCPA-facing customers and a common security-review blocker.
• Shipping a real retention policy instead of a promise. mail_log_retention_days (default 60, 0 keeps forever) gives you a configurable, auditable data-lifecycle control. That is a checkbox item in most vendor questionnaires ("how long do you retain email content?") and a defensible default you can quote in a DPA.
• Roadmap sequencing for a compliance story. Because contributions register with core's registries and run without the compliance package installed, you can ship email-log privacy now and let the broader compliance/DPO feature set land later — no forced dependency, no coordinated release.
• Build vs. buy for audit trails. The package now covers the three things teams usually hand-roll badly: recipient matching (EmailLog::forRecipient()), export/erasure hooks, and timed pruning. Adopting beats maintaining a bespoke email audit table with your own DSAR scripts.
• Support and incident-response use cases. Delivery forensics, "did the customer actually receive the notice?", and dispute resolution remain the day-one value; retention now bounds the liability and storage cost of keeping that history.
• Pricing/packaging input. Privacy export and erasure are credible differentiators for a paid tier or an "enterprise/compliance" add-on, while a 60-day default makes the free tier cheap to operate.

When to Consider This Package

• You send transactional or notification email from Laravel and need a queryable record of what went out, to whom, and when — beyond what your ESP dashboard retains.
• You have (or expect) data-subject requests. If a customer can ask "show me everything you sent me" or "delete my data," the contributor + forRecipient() pairing gives you a working implementation instead of a spike.
• You need a retention knob you can defend. A 60-day default with 0 as explicit "keep forever" is the right shape for a policy reviewed by legal; check that your jurisdiction and contract terms agree with the default before shipping.
• You want optional, not mandatory, compliance coupling. Nothing runs without the compliance package, so this is safe to install in apps that will never do DSARs — but it also means you get no privacy tooling until you adopt a host. If you need export/erasure out of the box with no additional package, look elsewhere.
• Look elsewhere if: you need per-message content redaction at write time, field-level encryption of message bodies, tamper-evident/immutable audit logs for regulated record-keeping, or retention policies per-tenant/per-mail-type rather than a single global setting. Also look elsewhere if you require a mature, widely-audited package — v0.x with a single new contributor release is early, and the privacy surface (forRecipient() matching semantics, what "erase" actually removes vs. anonymises) deserves a read of the source before you rely on it in a DSAR workflow.
• Watch the anonymisation ordering. The release notes explicitly read the address before the account is anonymised. Verify that ordering holds in your host's erasure sequence — a race here is a compliance bug, not a UI bug.

How to Pitch It (Stakeholders)

To executives: This release closes a gap that shows up in enterprise security reviews. We can now export or erase a person's email history on request and enforce a documented retention window (60 days by default, configurable) — the two questions legal and procurement ask most often about stored communications. It ships as an opt-in layer, so it costs nothing for customers who don't need it and becomes a credible paid-tier differentiator for those who do.

To engineering: The package registers EmailLogContributor with core's privacy registries, so export, erase, and prune all run through the host's existing pipeline — no bespoke DSAR endpoint, no coupling to filagora-compliance at install time. Retention is a single setting (mail_log_retention_days, default 60, 0 disables pruning). Two things to review before adoption: recipient matching reuses forRecipient() semantics (confirm it covers aliases and forwarded addresses), and the address must be captured before account anonymisation — make sure that ordering is enforced in our erasure flow and covered by a test. Given the v0.x version and the sensitivity of the surface, budget a short spike and a read of the contributor source rather than adopting blind.