Filament Activity Log Plus Laravel Package

Product Decisions This Supports

• Audit trail & compliance readiness (SOC 2, ISO 27001, HIPAA-adjacent, GDPR accountability). This package gives you a reviewer-facing activity log inside your admin panel without building one: who changed what, when, from where, grouped into a single "batch" per request/operation so a multi-model save reads as one story instead of five unrelated rows. The v1.1.0 security fix matters directly here — the logger previously persisted $hidden attributes and encrypted-cast values (MFA secrets, recovery codes, two_factor_*, API tokens) in plain text, because spatie/laravel-activitylog decrypts before reading. If you already ship this, your audit log may currently be a secret store in plaintext: treat remediation as a data-handling incident decision, not a routine upgrade.
• Support and incident triage. The "+N more" correction, the timezone-correct From/Until filter, and the fix that stops artisan/queue entries from being stamped 127.0.0.1 all make the log trustworthy for "who did this and from where." A log that lies about IPs or silently truncates related records is worse than no log — it produces confident wrong answers in customer escalations.
• Build vs. buy. Buy. The value is in the accumulated edge cases: pivot titles resolving past soft-deleted/scoped models, batch roots not being hijacked by last_login_at writes during login, index-friendly created_at range filtering, Octane-aware request detection. Each of these is a bug you would only discover in production, months in.
• Admin UX roadmap. The scoped stylesheet fix (:where(.activity-log-plus) .flex) means the log view no longer breaks your panel's responsive and dark: utilities — a real blocker if your ops team lives in dark mode or on mobile. This unblocks shipping the log view to non-engineer stakeholders.
• Upgrade sequencing decisions. Two upgrade paths are now unblocked: spatie/laravel-permission ^8.0 (previously pinned to v7 dev) and spatie/laravel-permission v6 role grants/revocations (RoleAttached/RoleDetached event names) now logging correctly. If you're mid-migration between permission v6 and v8, activity logging of role changes is no longer a reason to delay.

When to Consider This Package

Adopt when:

• You run Filament and need an audit log surfaced in the panel — the alternative is hand-rolling a resource, filters, and diff rendering.
• You need operational audit logging (who edited this record, from which IP, in which batch) rather than tamper-evident logging. This is a UI and convenience layer, not an immutable ledger.
• You're on spatie/laravel-activitylog v4+ and can accept the migration notes: legacy v4 rows need a manual UPDATE activity_log SET batch_root = 1, and down() will drop a batch_uuid column even if it pre-existed your adoption. Both need a change-management ticket, not a migrate on a Friday.
• Your threat model treats the activity_log table as sensitive. Post-1.1.0 it excludes hidden attributes, encrypted casts, and MFA columns by default — but you must still purge or rotate any credentials logged before this version, and verify activitylog.default_except_attributes in your own config after config:cache.

Look elsewhere when:

• You need WORM storage, cryptographic chaining, or external attestation — pair with a dedicated audit sink instead.
• You have no Filament panel; you'd be paying the plugin's weight for a logger you can wire directly.
• You cannot tolerate the plaintext-secrets window in pre-1.1.0 logs and have no way to rotate the affected tokens — that's a security review, not a package evaluation.

How to Pitch It (Stakeholders)

To executives: This is the audit trail for our admin panel — it answers "who changed this, when, and from where" without a custom build. The v1.1.0 release closes a real security gap: encrypted fields and API tokens were being written to the log in readable form. We should upgrade promptly, and separately confirm whether any live credentials touched the log so we can rotate them. After that, the log becomes safe to expose to support and ops staff, which shortens escalation cycles.

To engineering: Low-risk upgrade, one genuine security fix, and several correctness fixes worth taking. Scope: spatie/laravel-permission dev constraint now allows ^8.0; role grant/revoke events now handled on v6 as well as v7; the stylesheet is scoped to the plugin's own markup so it stops clobbering host dark: and responsive utilities (requires npm run build); date filtering now uses panel-timezone calendar days against raw created_at (index-friendly, replaces whereDate()); artisan/queue entries no longer get a synthetic 127.0.0.1; login/logout writes no longer steal the batch root; pivot titles resolve without global scopes. Migration caveats: the new migration indexes a pre-existing batch_uuid on activitylog v4 tables, down() only drops indexes that exist, and down() does drop batch_uuid even if it pre-dated us — document that before rollback drills. Legacy v4 rows need a one-time UPDATE activity_log SET batch_root = 1. Verify the expanded default except list survives config:cache in staging before promoting to production.