Weave Code
Filament Laravel Package
laravel-chronicle/filament
Filament plugin for Laravel Chronicle that surfaces audit logs in your admin panel. Browse, search, filter, and inspect recorded model events and field-level changes, with a dedicated resource for reviewing activity history and debugging data updates.
Read-only Filament panel plugin for Chronicle - browse and cryptographically verify your tamper-evident audit ledger.
Frequently asked questions about Filament
- How do I install laravel-chronicle/filament?
- Install it with Composer via composer require laravel-chronicle/filament, then register the plugin on the Filament panel where you want the audit resource to appear. It assumes an existing Laravel application with Filament and Laravel Chronicle already wired up to a ledger resource. The 1.5.0 release adds no new services, config keys, or migrations, so the install steps are unchanged from 1.4.0.
- Do I need to run migrations or publish config after installing this Filament plugin?
- No. This package is a read-only Filament panel plugin layered on top of an existing Laravel Chronicle audit ledger, so it ships no migrations of its own. Version 1.5.0 introduces no new config keys, published assets, or cache clears. A standard Composer update with a lockfile refresh is the entire migration path.
- Which Filament and Laravel versions does laravel-chronicle/filament support?
- The plugin is a Filament panel plugin and does not require a specific Laravel or Filament version beyond what version 1.4.0 already required. Release 1.5.0 does not change version constraints. Check your pinned composer.json constraints before updating, and confirm the Filament major you run is the one the plugin already targets.
- Does this plugin write to or modify my audit logs?
- No. The resource is read-only by design: you browse, search, filter, and inspect recorded model events and field-level changes, but you do not edit ledger entries from the panel. The only write path in Chronicle itself is GDPR erasure, which already had execution-time authorization before 1.5.0. The 1.5.0 change reinforces this read-only invariant rather than altering the ledger's integrity boundary.
- How does authorization work for the Chronicle resource in 1.5.0?
- Authorization is policy and gate based, with the resource relying on Filament's visible() checks at render time. Version 1.5.0 adds a re-check inside the existing action handlers, so a gated action refuses to execute when the caller is unauthorized, not just when the button is hidden. The release notes state the re-check uses the same gate as visible(); confirm in your own code that it is the identical ability and subject so the two checks cannot drift.
- What changed in laravel-chronicle/filament 1.5.0?
- Two things: an authorization re-check inside existing action handlers, and a new test (ExecutionTimeGuardTest) that pins the action registry. There are no new public APIs, migrations, or config keys, and authorized behavior is identical to 1.4.0. The release is best read as defense in depth against the known Filament footgun where visible() is a render-time-only control, not as a vulnerability fix in the ledger itself.
- Will upgrading to 1.5.0 break my CI if I registered custom actions on the resource?
- Possibly, and intentionally. The ExecutionTimeGuardTest is a structural tripwire that fails when the action registry grows without a matching denial test, so adding a custom gated action becomes a build-breaking event until you write a test proving it refuses at execution when unauthorized. Verify whether the test enumerates actions from your application's resource at runtime or from a static list in the package's own suite, since that determines real adopter CI impact. Treat this as a CI-policy change to communicate to your team, not just a security note.
- Can I search and filter audit entries by model, event, or field-level change?
- Yes. The resource is built for reviewing activity history: you can browse recorded model events, search across entries, and filter to narrow down the activity you care about. Individual entries can be inspected to see field-level changes and the details of each data update. This makes it practical for debugging unexpected data changes without querying the ledger by hand.
- Is laravel-chronicle/filament safe to run in production?
- Technical risk for 1.5.0 is assessed as low. Render-time gating already existed, the sole write path (GDPR erasure) already enforced authorization at execution, and exports run through a queued job so decrypted data is never returned synchronously. Pre-fix exposure was limited to triggering a verification or enqueuing an export the caller's UI would not have shown them. The residual risk is a class-of-defect one: any future gated action added without an execution-time check reintroduces the gap.
- Are denied action invocations recorded in the ledger or application logs?
- The 1.5.0 release notes do not document whether denied invocations are recorded in the ledger, application log, or security telemetry. If auditability of denials matters to you, check the action handlers in the package source or raise it with the maintainer before relying on it. Also confirm that any denial notification does not leak the existence of actions or resources to unauthorized callers.
Weaver
How can I help you explore Laravel packages today?