Filament Activity Log Plus Laravel Package

Technical Evaluation

Architecture fit. The package is a Filament panel plugin layered on spatie/laravel-activitylog (v4 table), adding operation batching, a viewer UI, and Filament-native filters. That is a good architectural fit for Laravel/Filament monoliths or modular monoliths that already use Filament for back-office operations and need a lightweight audit trail without standing up a separate SIEM. It is a poor fit for event-sourced systems, high-volume append-only audit requirements with regulatory retention/WORM needs, or multi-tenant estates where log isolation is a hard requirement — the package is a UI and batching convenience over a shared table, not an audit platform.

Integration feasibility. Straightforward for a team already on Filament + activitylog: composer update, publish/merge config, run migration, rebuild assets. The complications are not install mechanics but data and state:

• Historical secret exposure (critical). Before v1.1.0, LogsActivityPlus logged $hidden attributes and encrypted-cast values in plaintext — including Filament MFA app_authentication_secret, recovery codes, two_factor_*, and API tokens — because spatie decrypts casts before the logger reads them. This means existing activity_log rows may contain live secrets. Upgrading stops new leakage but does not remediate what is already stored. Treat this as a security incident, not a routine dependency bump.
• Migration/rollback footguns. The migration now indexes a pre-existing batch_uuid column (activitylog v4 upgrade path), and down() drops batch_uuid even if it pre-existed. Legacy v4 rows require a manual UPDATE activity_log SET batch_root = 1. Rolling back on a v4-origin database can destroy a column the host still depends on.
• Behavioural changes. The From/Until filter now interprets calendar days in the panel timezone and compares raw created_at (index-friendly). This is a correctness and performance improvement, but results will shift for non-UTC panels, and dashboards/exports built on the old whereDate() UTC semantics may no longer reconcile.
• Frontend workaround removal. The compiled stylesheet is now scoped under :where(.activity-log-plus). Any host-level CSS overrides added to fight the previous global utilities will need to be removed, and assets must be rebuilt (npm run build).
• Version matrix. The spatie/laravel-permission constraint now permits ^8.0 on the dev constraint, tested on 8.3, with role events unchanged; role grants/revocations are also logged on v6 via RoleAttached/RoleDetached. This broadens support but is a dev-constraint-only signal — production validation on 8.x is still on the integrating team.

Technical risk (summary).

Key questions.

1. How long has the pre-1.1.0 version been in production, and who/what had read access to activity_log (DBAs, backups, log exporters, BI tools)?
2. Have Filament MFA secrets, recovery codes, and API tokens that may have been logged been rotated? If not, when?
3. What is the retention/purge policy for activity_log, and can we redact historical rows without breaking batch roots or the viewer?
4. Which spatie/laravel-permission major is in production — v6, v7, or v8? Has role grant/revoke logging been verified end-to-end?
5. Is the panel timezone non-UTC? Which dashboards, exports, or compliance reports depend on the old UTC-day filter results?
6. Did the host add CSS overrides to compensate for the old unscoped stylesheet? Who owns removing them and re-verifying dark mode/responsive layouts?
7. Does the application run under Octane and/or queue workers for write paths? Are we validating the new ActivityBatch::start(http: true) behaviour in staging?
8. Is the batch_uuid column pre-existing (v4 upgrade) or package-created? What is the rollback plan, and is down() acceptable in this environment?

Integration Approach

Stack fit. Assumes Laravel 10/11+, Filament 3.x panel, spatie/laravel-activitylog v4, and spatie/laravel-permission v6–v8. The package is a presentation and batching layer, so it should be integrated as an operational/compliance-adjacent feature with a named owner, not as an incidental composer dependency.

Migration path.

1. Freeze and inventory. Pin the current version, snapshot activity_log schema and row counts, and identify whether batch_uuid is pre-existing.
2. Exposure assessment. Query historical rows for MFA columns, two_factor_*, token-like fields, and any $hidden/encrypted-cast attributes. Do this before upgrading so the remediation scope is known.
3. Secret rotation. Rotate API tokens, MFA secrets/recovery codes where practical, and any credentials confirmed in logged payloads. This is independent of the package upgrade.
4. Redact/purge. Remove or mask historical sensitive values. Decide whether to delete affected rows, null the properties, or truncate; preserve batch roots if the viewer depends on them.
5. Upgrade package. Composer update to v1.1.0; merge published config so activitylog.default_except_attributes includes MFA columns and the package except list is intact.
6. Run migration with pre-checks. Verify batch_uuid existence and index state before migrating. On legacy v4 data, run the documented UPDATE activity_log SET batch_root = 1. Do not rely on down() as a rollback strategy — restore from backup or write an explicit reverse migration.
7. Rebuild frontend. npm run build; remove host CSS overrides previously added for the plugin; verify responsive and dark: utilities on the host panel.
8. Validate behaviour. Test From/Until across timezone boundaries (including DST), confirm raw created_at index usage via query plan, verify "+N more" counts, role grant/revoke logging on the actual permission version, and artisan/queue IP behaviour (including Octane).

Compatibility. The permission v8 allowance is a dev constraint; treat 8.x as supported-in-test, not yet proven in this estate. The timezone filter change is behaviourally incompatible for any downstream consumer that assumed UTC-day whereDate() semantics.

Sequencing. Security remediation must precede or run in parallel with the upgrade; the upgrade alone does not clean historical rows. Schedule the CSS rebuild and filter-semantics validation with the same release window, because both are user-visible.

Operational Impact

Maintenance. The except list is now a security control, not a cosmetic setting. New encrypted casts, MFA fields, and token columns must be added deliberately; a future model change that introduces a sensitive encrypted attribute will leak unless the default except list or model-level $hidden covers it. Assign ownership of the config and add a review step to any model/schema change touching credentials.

Support. Expect a short spike in tickets after the timezone filter change ("my report is off by a day") and after CSS scoping ("dark mode looks different"). The "+N more" semantic change may also prompt questions from operators who used it as an entry count.

Scaling. The raw created_at comparison is the right call for large tables — it lets the existing index serve the filter rather than forcing a per-row date conversion. But the package still writes one row per activity entry plus batch metadata; at high write volume, activity_log growth, index bloat, and retention become the dominant operational concerns, not the plugin. Confirm purge/partition policy and monitor table size and index health.

Failure modes.

• Silent secret re-exposure. Encrypted-cast or hidden attributes not covered by config are logged in plaintext; the failure is invisible until someone reads the log.
• Destructive rollback. down() drops batch_uuid even when it pre-existed, breaking v4-origin installs and any host code using that column.
• Migration failure on legacy schema. Missing batch_uuid or partially applied indexes leave the plugin unusable and may require manual DBA intervention.
• Filter drift. Non-UTC panels produce different date-boundary results than before; compliance exports may no longer reconcile with prior periods.
• Attribution gaps. Queue/artisan writes no longer get a synthetic 127.0.0.1, which is more accurate but may expose gaps in how non-HTTP activity is attributed — verify that batch roots still group correctly.
• Frontend regression. Scoped CSS is correct, but host overrides left in place can now double-apply or conflict; rebuild is mandatory.

Ramp-up. Low for a Laravel/Filament developer — install and config are conventional. Moderate for the operational owner, who must understand the audit-log security model, the timezone filter semantics, the batch-root/batch_uuid relationship, and the migration's legacy-data caveats. Budget a half-day of security review and a half-day of QA per panel locale, plus incident time for historical secret remediation.