- How do I install rmsramos/activitylog in a Laravel Filament application?
- Install it with Composer alongside spatie/laravel-activitylog and Filament, then register the plugin in your Filament panel provider. Because the package is an integration layer rather than a standalone logger, it assumes activity records are already being written by Spatie's package. Publish any provided assets or configuration if your setup requires customizing the resource before wiring it into a panel.
- Does rmsramos/activitylog support spatie/laravel-activitylog v5?
- Yes. Version 4.1.0 of this package is tolerant of both Spatie v4 and v5 log shapes. It reads diffs from attribute_changes first and falls back to the older properties.old and properties.attributes keys, so rows written under either schema will render correctly. That dual-path design means a phased migration does not require a maintenance window or a big-bang cutover.
- Do I still need to install spatie/laravel-activitylog separately?
- Yes. This package does not write activity records itself; it renders and acts on records produced by spatie/laravel-activitylog. You keep using Spatie's traits and helpers to record who changed what and when. That keeps the blast radius of this dependency confined to your admin and audit surface rather than the write path across your domain.
- Which Laravel and Filament versions does this package require?
- The package targets Laravel applications running Filament, since its entire value is the Filament-facing resource and restore actions. Check the composer.json constraints for the exact Laravel and Filament version ranges supported by your chosen release. Because it tracks upstream Spatie releases via point versions, pinning a specific version and reviewing changelogs before upgrading is recommended.
- Why are the activity diffs showing empty in my Filament activity log resource?
- If neither attribute_changes nor the older properties.old and properties.attributes keys are populated, the renderer degrades quietly and shows empty diffs rather than throwing an exception. This is usually a data-quality issue from partially migrated or backfilled rows, not a rendering bug. Add explicit test coverage that renders a row from each schema shape so a silent presentation failure is caught before your audit stakeholders notice it.
- How do I migrate the subject_returns_soft_deleted_models config key to include_soft_deleted_subjects?
- Rename the key in your published Spatie activitylog configuration as part of the upgrade, and treat it as a required step rather than optional cleanup. A stale key name will not throw an error, but it changes which records appear in the audit view, so soft-deleted subjects can silently drop out. Assign clear ownership for this change in your repository to avoid config drift between environments.
- Can I safely drop the batch_uuid column when upgrading Spatie?
- Only after confirming nothing in your application consumes it. If you have custom queries, exports, or grouping UI that rely on batch_uuid, dropping the column destroys that batch-grouping data permanently. Rolling this package back to 4.0.4 does not restore the column or the data, so rollback is not a clean mitigation for the schema step. Audit your consumers first, then run the migration.
- Are restores from the Filament resource logged as new activity?
- The restore actions call withoutLogging() and withChanges() behind method_exists guards, so the logging behavior depends on the Spatie version installed. On versions that provide those methods, the restore is performed without emitting an extra activity entry. Treat the method_exists guard as part of your upgrade planning, since it determines whether you can pin Spatie independently of this package.
- How should I test this package before relying on it for audit trails?
- Do not rely on a green CI run alone. Write tests that render activity rows in each supported log shape, including the edge case where both diff sources are absent, and verify what the UI shows in that situation. Also test that soft-deleted subjects still appear after the config key rename, since that regression is silent rather than an exception.
- Is rolling back to 4.0.4 a safe mitigation if the upgrade breaks something?
- Not for the schema portion of the upgrade. If you have already run Spatie's migration and dropped batch_uuid, rolling this package back will not restore the column or the batch-grouping data that lived in it. Rollback is reasonable for a pure rendering regression, but plan the database step as irreversible and confirm no consumers exist before you execute it.