Filament Record Lock Laravel Package

Product Decisions This Supports

• Feature investment: Add safe concurrent editing to Filament 5 admin panels with pessimistic record locks, heartbeat renewal, stale-save refusal, read-only fallback, and gated unlock/takeover flows.
• Roadmap readiness: Supports enterprise and multi-tenant back-office use cases: configurable table/connection, integer/UUID/ULID keys, ten translations, record-lock manager, event hooks, and scheduled pruning.
• Build vs buy: Strong candidate to buy/use rather than build. The package already covers model/page traits, heartbeat lifecycle, release-on-leave via sendBeacon, lock-aware actions, bulk release, stale detection, and migration compatibility with kenepa/resource-lock.
• Use cases: CRM/account records, support tickets, finance/ops workflows, inventory, content moderation, and any Filament Edit or modal-edit flow where two admins can overwrite each other.
• Policy decisions: Define who may “Unlock and edit,” when takeover is allowed, lock timeout/UX expectations, tenant scoping requirements, and how lock visibility is surfaced via RecordLockColumn and the “Record locks” manager.
• Risk controls: Locks reduce lost updates but are not an authorization boundary or a replacement for database constraints/transactions. Pessimistic locking can frustrate users if timeouts and unlock permissions are not designed well.

When to Consider This Package

• You run a Filament 5 application where multiple users edit the same records and lost updates are costly.
• You need pessimistic locking with heartbeat renewal, save refusal when the lock is lost, and detection of records changed while the lock lapsed.
• You want built-in UI affordances: blocking notice, “Back to list,” “View read-only,” gated “Unlock and edit,” lock columns, release actions, and a read-only lock manager.
• You need UUID/ULID support, configurable lock storage, translations, tenant-panel behavior, and operational hooks such as RecordLockTakenOver and record-lock:prune.
• You are migrating from kenepa/resource-lock and can use the documented migration path where API compatibility applies.
• Look elsewhere if you are not on Filament 5, need real-time collaborative editing, API-only optimistic concurrency, long offline editing sessions, or cannot operate the scheduled prune command. Also verify tenant scoping and unlock permissions before adopting.

How to Pitch It (Stakeholders)

Executives: This is a ready-made concurrency-control layer for Filament admin workflows. It reduces lost updates and support incidents, improves multi-user operational safety, and avoids custom-building lock lifecycle, UI, notifications, cleanup, and migration paths. Adopt behind a controlled rollout, with clear unlock policies and tenant scoping.

Engineering: v1.0.0 adds HasLocks, UsesResourceLock, UsesSimpleResourceLock, heartbeat renewal, sendBeacon release, lock-guarded saves and actions, RecordLockColumn, release/bulk-release actions, a read-only lock manager, RecordLockTakenOver, and a scheduled record-lock:prune command. Review fixes harden lock state, MySQL/PostgreSQL behavior, string-key eager loading, tenant-panel manager scoping, atomic takeover, and unknown morph types. Plan to schedule pruning, configure the lock table/connection, test key types and tenant scoping, and define permission-gated unlock/takeover.