Weave Code
Resource Lock Laravel Package
kenepa/resource-lock
Kenepa Resource Lock is a Filament plugin that prevents concurrent edits by locking records while someone is editing. It shows who holds the lock, displays friendly warnings, and supports configurable lock duration and authorization policies.
Filament Resource Lock is a Filament plugin that adds resource locking functionality to your site.
Frequently asked questions about Resource Lock
- What is kenepa/resource-lock used for in Filament?
- Kenepa Resource Lock is a Filament plugin that adds advisory locking to Eloquent records so two editors cannot open the same record in an edit form at the same time. It shows who holds the lock, displays friendly warnings, and supports configurable lock duration and authorization policies. It solves editor collision UX, not database-level write-write consistency.
- How do I install kenepa/resource-lock in a Laravel app?
- Install it with Composer, register the Filament plugin in your panel provider, then publish and run the lock table migration and publish the config file if needed. A greenfield install is typically measured in hours. The real effort is behavioral verification on your Filament page types, not the installation itself.
- Which Filament and Laravel versions does kenepa/resource-lock support?
- Version 4.0.0 adds Filament 4.x support and is coupled to Filament ^4.0; the major bump exists because the plugin can no longer support Filament 3 and 4 from one codebase. If you are still on Filament 3, pin 3.0.x instead. Check the package composer.json for exact PHP and Laravel constraints against your supported matrix.
- How do I configure lock duration and lock expiry?
- Kenepa Resource Lock supports configurable lock duration through its published config file. Publish the config and set the duration to match how long your editors typically hold a record open. Also verify whether expiry is TTL-based or refreshed by a heartbeat, because that determines how stale locks are reclaimed.
- How are locks released when a user saves, closes the browser, or their session expires?
- The plugin acquires a lock when the edit page opens and releases it on save, close, or expiry. You should explicitly test release behavior on browser close, session expiry, and failed validation, because advisory locks can leak when clients disconnect ungracefully. Document the expected behavior for your support team.
- What happens if a lock becomes stale or orphaned?
- Any advisory lock scheme can leave orphaned locks when a client disconnects ungracefully, so robust expiry and refresh behavior is critical. Confirm how your version expires locks, and document a manual recovery path such as clearing the relevant lock record. Without that, users can be locked out of records and generate support tickets.
- Are locks tenant-scoped and aware of authorization policies?
- The plugin supports authorization policies and displays who holds a lock, but tenant scoping and policy-aware behavior should be verified rather than assumed. Check whether lock keys are scoped correctly across tenants and whether users who can view but not edit a record are handled sanely. You may need customization for multi-tenant panels.
- Does kenepa/resource-lock work with relation managers, modal editing, custom pages, and bulk actions?
- Because the plugin hooks the Filament edit-page lifecycle, you must verify behavior on custom pages, relation managers, modal-based editing, and bulk actions. Standard edit pages are the best-supported path, while modal and bulk flows may behave differently. Test acquisition, release, and warning UI on each page type you rely on.
- How does kenepa/resource-lock compare to database optimistic locking?
- It is an advisory UI-level lock that prevents two editors opening the same record form concurrently; it does not provide write-write consistency. Database optimistic locking or unique constraints still matter for data integrity. Use this package for editor collision UX, not as a substitute for transactional guarantees.
- Is kenepa/resource-lock actively maintained and what is the upgrade path from 3.0.1 to 4.0.0?
- The 4.0.0 release tracks Filament 4 and has a thin changelog with no explicit breaking-changes or upgrade-guide section, so treat the upgrade as sequenced with your Filament 4 migration. The package has a single primary maintainer, which is a real maintenance risk. Confirm whether 3.x continues to receive fixes and check whether the lock table schema or config keys changed before upgrading.
Weaver
How can I help you explore Laravel packages today?