- How do I install and set up filament-resource-lock in a Laravel app?
- Run composer require androsamp/filament-resource-lock, then php artisan filament-resource-lock:install, then php artisan migrate. The installer publishes config/filament-resource-lock.php, the lock and audit table migrations, and a resources/js/filament-resource-lock/echo.js shim. Be aware it also injects an import statement into your resources/js/bootstrap.js, so review that diff and account for it in your asset pipeline before merging.
- What Laravel, PHP, and Filament versions does this package require?
- It requires PHP ^8.3, Laravel ^12.0 || ^13.0, and Filament ^5.0. That is an aggressive floor: there is no support for Filament v3 or v4, so adopting the package on an older panel effectively means a Filament upgrade first. Because Filament v5 itself is still early, a minor Filament upgrade could break the package with no upstream guarantee of a patch.
- Should I use heartbeat polling or broadcast mode with Laravel Echo?
- Heartbeat mode needs no extra infrastructure: the Livewire component polls for lock state, which is fine for most admin panels. Broadcast mode pushes updates through Laravel Echo for lower latency, but it requires Redis plus an Echo-compatible service such as Reverb, Pusher, or Ably. If you do not already run Echo, start with heartbeat and only move hot records to broadcast.
- Why is the audit history not recording changes on my resource?
- The audit trait records before/after snapshots by wrapping the page's save() method. If any EditRecord page overrides save(), afterCreate(), or uses custom persistence, the wrapper is silently bypassed and audit stops working for that resource. The fix is to manually reimplement the before/after bridges in those pages, so audit every customized page before rollout. You also need the HasResourceAudit trait applied to the edit and create pages you want tracked.
- What happens when two users or two browser tabs open the same record?
- User A acquires the lock, and User B sees the form and save disabled with the lock owner displayed, plus an optional ask_to_unblock request. A unique-constraint violation when opening the same resource in two tabs was fixed in v2.1.2, and a form-refresh bug during unlock handoff was fixed in v2.1.1. Both were post-release fixes, so pin a version and test multi-tab and handoff flows yourself before relying on it.
- Why do users get a stuck lock and how do signed release routes relate to APP_URL?
- The soft release route is a signed URL, so validation depends on APP_URL matching the actual host in every environment. If APP_URL is wrong behind a proxy or on staging, the link fails and users are left holding a lock they cannot release. Verify APP_URL is correct and stable per environment, and enable save_and_unlock or ask_to_unblock so handoffs do not depend solely on that link.
- How do I show the lock owner in a Filament resource list table?
- The package ships two table columns you can drop into your resource's table schema to surface lock state and the owning user in list views. Integration is trait-based rather than a panel plugin, so nothing needs to be registered on the panel. Add HasResourceLocks to the Eloquent model and InteractsWithResourceLock to the EditRecord page first.
- How do custom fields work in the audit diff and rollback?
- Use the HasAuditDiffPreview concern to describe how custom fields should be rendered in the per-field diff. Any custom field you do not handle deliberately falls back to a plain before/after value comparison, which is readable but less useful for complex fields like repeaters or rich text. Rollback is selective, so you can restore individual field values rather than the whole record.
- Is filament-resource-lock production-ready, and what are the alternatives?
- Treat it as a forward-looking bet: the design is sound and installation is low-friction, but it has roughly 7 stars and 0 dependents, so there is no third-party evidence the concurrency edge cases hold under load. It is also a single-maintainer dependency guarding a correctness-critical concern, record overwrite prevention. For core records, consider scoping it to a handful of hot resources and keeping an in-house fallback, or evaluating a simpler optimistic-locking check you control.
- How can I test resource locking in my test suite?
- The README does not document dedicated testing helpers, so test through Livewire: use Livewire::test on your EditRecord page, open it as a second user, and assert the form is disabled and the lock owner is shown. Keep the database lock store in your test config rather than Redis, and clear lock tables between tests so state does not leak. If you use broadcast mode, fake the broadcast events so assertions stay deterministic.