Activitylog Laravel Package

Product Decisions This Supports

• Ship the audit trail as a user-facing feature, not a database table. This package turns spatie/laravel-activitylog records into a navigable admin surface (list, diffs, restore actions). That converts a "we log everything" engineering checkbox into a support and compliance capability — support agents and account managers can answer "who changed this and when" without a ticket to engineering.
• Build vs. buy: buy. The core logging is already covered by Spatie; this package is the thin presentation layer. Rebuilding an equivalent viewer (filters, pagination, attribute diff rendering, restore-without-relogging) is days of work plus ongoing maintenance against two upstream majors. Adopt rather than build.
• Roadmap input — v4.1.0 removes a blocker. Until now, teams on spatie/laravel-activitylog v5 (the current major) could not use this UI without patching it. That dependency pin was a hard "no" for any greenfield admin panel. v4.1.0 clears it, so "audit log viewer" can move from blocked to schedulable on the roadmap.
• Soft-delete / restore visibility is a product decision this unlocks. The release adds restore actions that suppress their own logging and pass change context when the underlying methods exist. Practically: admins can restore a deleted record from the audit screen without polluting the audit trail with their own restore event. That's a policy choice worth confirming with Legal/Compliance before enabling — some teams want restores logged as first-class events.
• Upgrade sequencing decision for existing installs. Adopting v4.1.0 is a patch-level bump with no breaking changes, but moving to Spatie v5 is a separate, larger decision: it requires Spatie's own schema migration (attribute_changes column added, batch_uuid dropped) and a config key rename (subject_returns_soft_deleted_models → include_soft_deleted_subjects). Product framing: the viewer is safe to upgrade now; the data-model migration is a planned, separately scheduled change.
• Use cases this makes cheap to green-light: customer-facing "activity" tabs on records, internal CRM/ops history panels, compliance evidence for SOC 2 / ISO 27001 access-and-change reviews, and post-incident forensics ("what did this admin do in the 20 minutes before the outage").

When to Consider This Package

Adopt when:

• You are already on Laravel with Filament as your admin stack and spatie/laravel-activitylog as your logging layer. This package is a UI on top of both; it is not a replacement for either.
• The need is human-readable viewing of activity: who, what, when, before/after diffs, filterable by subject and causer.
• Your volume fits an interactive admin panel — thousands to low millions of rows, queried on demand. The viewer is a paginated resource, not an analytics engine.
• You want dual-version tolerance during a Spatie upgrade window: v4.1.0 reads v5's attribute_changes and falls back to v4's properties.old / properties.attributes, so mixed-version environments still render during rollout.

Look elsewhere (or extend it) when:

• No Filament. The package is coupled to Filament's resource/page conventions. On a plain Blade/Livewire/Inertia or Nova admin, this buys you nothing — query Spatie directly.
• Audit integrity is a regulatory requirement. This is a viewer, not a tamper-evident store. If you need WORM storage, cryptographic chaining, or retention guarantees, the source of truth must be an append-only sink (object storage, dedicated audit service, SIEM). Use this as a convenience lens over a small window, not as the compliance system of record.
• High-volume or long-retention analytics. Diff rendering per row is expensive. If the primary use case is dashboards, anomaly detection, or export to a warehouse, ship logs to a data store and query there.
• You haven't yet upgraded Spatie. v4.1.0 is compatible, but the schema migration is on you. Plan the migration (add attribute_changes, drop batch_uuid, rename the config key) as a discrete deploy with a backfill and a rollback path; do not let it ride along inside a routine dependency bump.
• Single-maintainer risk is unacceptable. This is a small-community package with a single primary maintainer. If your availability requirements are strict, plan to vendor the source or budget for internal forking — v4.1.0's contribution from an outside author is a positive signal, not a guarantee.

Adoption checklist: pin to ^4.1; verify the Spatie major in composer.lock matches your migration state; test the restore action against a soft-deleted model in staging and confirm whether restores should be logged (the new withoutLogging() behavior is a policy default, not a neutral one); add a smoke test asserting v4-era log rows still render after you migrate the schema.

How to Pitch It (Stakeholders)

For executives (one paragraph): We get an audit-history screen for our admin panel essentially for free. The underlying event logging is already a well-established open-source library we're standard on; this is the interface layer that makes it usable by support, ops, and account teams instead of only by engineers reading a database. The newest release (v4.1.0, a non-breaking patch) removes the dependency blocker that prevented us from adopting it on our current stack, so this is now a small, schedulable piece of work rather than a research project. It reduces support escalations on "who changed this record" questions and gives us a credible evidence trail for security reviews and customer audits. The cost is a composer dependency plus a one-time schema migration on the logging library; the payoff is a capability we would otherwise build and maintain ourselves. Main caveat, stated plainly: it is a viewer, not a tamper-proof audit system — if we ever face a formal regulatory retention requirement, we'll need an append-only store behind it.

For engineering (the practical summary): This is a Filament UI over spatie/laravel-activitylog. Upgrade to ^4.1 — it's a patch release with no breaking changes and no code changes required on our side. The headline is Spatie v5 support: diffs are read from attribute_changes with a fallback to v4's properties.old / properties.attributes, so old and new log rows render correctly side by side. Restore actions now call withoutLogging() and withChanges() behind method_exists guards, so they work on both Spatie majors. The Spatie v5 migration is not included — we own that: add the attribute_changes column, drop batch_uuid, rename subject_returns_soft_deleted_models to include_soft_deleted_subjects. Treat that as a separate PR with a backfill and a staging verification pass, not as part of the dependency bump. Also worth a deliberate decision rather than a default: restores performed from the audit screen no longer generate their own log entry — confirm that matches our audit expectations before enabling the action in production. Given the single-maintainer project, consider pinning exact minor versions and keeping a fork path in the back pocket.