Filament Activity Log Laravel Package

Technical Evaluation

Architecture fit. This is a thin presentation layer, not a logging engine. All actual capture is delegated to spatie/laravel-activitylog, which is mature, widely deployed, and well documented; the package under review contributes Filament resources/pages, filters, and a viewer UI on top of Spatie's activity_log table. That separation is architecturally favorable: the durable asset (the audit data and its schema) belongs to a well-maintained upstream, while the replaceable asset (the admin UI) is the small third-party dependency. If the plugin is abandoned, we lose a UI, not our audit trail.

Integration feasibility. Low effort for a team already on Filament. Expected shape: composer require waseet/filament-activity-log, register the plugin in the relevant PanelProvider, ensure Spatie's migration is published, and apply the LogsActivity trait to models we want audited. Assumes Laravel 10/11, PHP 8.1+, and Filament 3.x — these constraints must be confirmed against composer.json rather than assumed. No service-layer or data-model changes are required, which keeps the blast radius contained to one panel.

Technical risk.

• Maintainer concentration. 72 stars, 0 dependents, and a single-maintainer profile. We would be an early adopter with no public evidence of production use at scale.
• Namespace/repo mismatch. The package is published under waseet/* but hosted at noxoua/*, suggesting a transfer or fork. This is a supply-chain and continuity signal worth resolving before adoption (confirm the canonical repo and Packagist ownership).
• Filament major-version coupling. Filament v4 is a breaking release; plugins of this size typically lag by weeks-to-months. Our upgrade path for the admin panel becomes gated on a volunteer maintainer.
• Low opportunity score (1.14). Consistent with a narrow, single-purpose add-on — not a red flag in itself, but it caps the ecosystem support we can expect.
• Licensing is clean. MIT is permissive and commercially safe; no copyleft exposure.

Key questions.

1. Which Filament and Laravel versions are declared in composer.json, and is there an open issue or branch for Filament v4?
2. Does the viewer respect Laravel policies/gates, or is access controlled solely by panel access? Can we scope visibility by tenant or by causer?
3. How does it handle activity_log at scale — server-side pagination, indexed filters, or full-table loads?
4. Is properties rendered verbatim? We need PII redaction and a whitelist of audited attributes before this faces non-technical staff.
5. Are there retention/purge commands, or do we own that entirely?
6. What is the release cadence and issue-response history over the last 12 months?

Integration Approach

Stack fit. Targets the standard Laravel + Filament admin stack with Spatie activitylog v4. It is additive: no changes to existing models beyond opting into the LogsActivity trait, and no changes to our persistence layer. Teams without Filament get nothing from this package — that is the gating precondition.

Migration path. Two-track. (1) Stand up Spatie first: publish its migration, define the Activity model and morph map, and enable logging on a small set of high-value models. (2) Layer the plugin UI on top in a non-production panel. If we have pre-existing audit data in bespoke tables, plan a one-time backfill into activity_log — the plugin has no opinion on historical data. Greenfield adoption is materially cheaper than retrofitting.

Compatibility. Pin exact versions of filament/filament, spatie/laravel-activitylog, and this plugin together, and record them in a compatibility matrix. Verify: panel boots without error, resources are discovered, filters render, and the morph map resolves subject types correctly (a common silent failure). Treat Filament major upgrades as requiring an explicit plugin-compatibility check.

Sequencing.

1. Confirm license, repo provenance, and version constraints; fork to our VCS for supply-chain safety.
2. Install Spatie + migration; enable LogsActivity on 2–3 models in staging.
3. Install and register the plugin in a staging panel; validate UI and query behavior against a seeded dataset (~1M rows) to expose performance limits early.
4. Define access control (policy/gate), PII redaction rules, and retention policy.
5. Production rollout behind panel permission; document the fallback plan.

Fallback. Budget 1–2 engineer-days to build a minimal custom Filament resource over activity_log. This is the decisive mitigation: it converts an abandonment risk into a bounded cost, and should be scoped before commitment rather than after.

Operational Impact

Maintenance. Small code surface to own if forked, but we inherit the maintenance obligation on Filament upgrades. Recommend vendoring/forking into our VCS at adoption time and pinning, so an upstream disappearance does not block a panel upgrade. Track upstream releases quarterly.

Support. Community-only, no SLA, no vendor. Upstream Spatie is well supported and absorbs most of the debugging burden; failures will concentrate in the UI layer and are diagnosable. Assign a named internal owner for the plugin so it does not become orphaned on our side.

Scaling. The real scaling risk is the log table, not the plugin. activity_log grows monotonically; without retention it will dominate the database. Required before production: composite indexes on (subject_type, subject_id) and (causer_type, causer_id), a date-range filter enforced in the UI, and a retention/purge job (e.g., 12–24 months, or per compliance requirement). At high volume, consider partitioning by month or pointing reads at a replica. Validate the viewer's pagination is server-side — a naive ->all() load is a production outage waiting for month six.

Failure modes.

• Silent non-logging: misconfigured morph map or trait omission means events simply are not recorded; add a smoke test asserting an activity row is created on a representative update.
• Large-table slowdown: unfiltered queries time out the panel; mitigate with indexes, default date scoping, and pagination.
• Upgrade breakage: Filament major bump breaks the plugin; mitigate via pinning and the custom-resource fallback.
• PII leakage: raw properties visible to staff, including old/new values of sensitive fields; mitigate with $logAttributes/$logOnlyDirty, attribute exclusions, and property redaction.
• Audit integrity: if logs are editable/deletable via the UI, the trail is not evidentiary; confirm the plugin is read-only or restrict deletion to a privileged role.

Ramp-up. Half a day for a developer already fluent in Filament; 1–2 days including Spatie configuration, policy wiring, and redaction rules. Documentation quality is the unknown — assume thin docs and plan for source reading on the access-control and filtering behavior.