Filament Resource Lock Laravel Package

Product Decisions This Supports

• Build vs. buy for optimistic-concurrency UX. This package covers a narrow but recurring need — preventing two admins from editing the same record and silently overwriting each other. It supports a "buy/borrow" decision over custom lock tables, middleware, and Filament action wiring, letting the team spend roadmap capacity on differentiated features instead.
• Feature scope for admin panels and back-office tooling. Directly enables or de-risks: edit-screen lock acquisition, lock expiry/heartbeat handling, unlock-by-owner, and "locked by X" surfaced states. These are usually table-stakes asks from ops/support teams once a panel has more than a handful of editors.
• Concurrent-editing roadmap decisions. If the long-term direction is real-time collaborative editing (CRDT/OT or live presence), the lock model is a stepping stone, not the destination. Deciding to adopt this now is a decision to defer collaborative editing — worth making explicitly rather than by default.
• Multi-tenant and permissions design. The v2.2.1 fix removing an unscoped exists() query in isLocked() matters for product correctness: global scopes (tenant, soft-delete, visibility) are how most SaaS admin panels isolate data. A lock check that ignores them can report false positives/negatives across tenants. This release makes the package safer to ship in multi-tenant products, which is a roadmap-relevant signal, not just a bug fix.
• Data-integrity and audit posture. Locks plus the unlocked-relation fix reduce stale UI states ("still shows locked after I released it"), which translates into fewer support tickets and fewer accidental overwrites — useful evidence for compliance/audit conversations about change control.
• Release hygiene as a procurement input. Two community PRs merged within a patch release shows active maintenance and a responsive maintainer — relevant when deciding whether to standardize on this across multiple panels.

When to Consider This Package

Consider adopting when:

• You run Filament admin panels with multiple editors on the same records, and silent overwrites are a real or anticipated support burden.
• You need record-level locking with minimal custom code — the value is the Filament integration (actions, table columns, UI states), not the lock primitive itself.
• Your app uses global scopes for tenancy or visibility, and you need the lock check to respect them (the v2.2.1 isLocked() fix is the reason this now qualifies).
• Locks are advisory, not authoritative: the product can tolerate a lock being bypassed by a determined user or a direct API write.

Look elsewhere or build in-house when:

• You need hard, transaction-level guarantees (row-level DB locks, SELECT ... FOR UPDATE, optimistic version columns) enforced on every write path, including APIs and imports.
• You need real-time collaborative editing or presence; a lock table adds friction without solving convergence.
• You require long-term vendor support, SLAs, or a security review — this is a small, single-maintainer ecosystem package at v2.x, and the isLocked() scoping bug is a reminder that edge cases are still being found.
• Your lock semantics are complex: hierarchical locks, queue/async editors, cross-record dependency locking, or lock inheritance.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost add-on for our admin tooling that stops two people from overwriting each other's edits — a class of bug that produces bad data, manual cleanup, and support load. It's a mature-enough 2.x package with active maintenance; the newest patch fixes a multi-tenant data-isolation flaw and a stale-UI bug, so it's now appropriate for our environment. Effort is days, not weeks, versus building and maintaining equivalent locking logic ourselves. Recommendation: pilot on one high-traffic admin resource, measure overwrite incidents and support tickets before and after, then decide on wider rollout.

To engineering: Scope is a Filament plugin providing record-level locks with acquire/release flows and locked-state UI. v2.2.1 is a patch, no breaking changes: it fixes isLocked() running an exists() query that ignored global scopes (relevant to our tenant and soft-delete scopes) and clears the cached lock relation on unlock to avoid stale "locked" states after release. Integration cost is low but not zero — we must decide lock TTL/heartbeat, behavior on lock expiry mid-edit, and how locks interact with our API write paths, which this package does not protect. Please also confirm the lock check respects our tenant global scope in an integration test, since that was the class of bug just fixed. Treat this as advisory locking; database-level concurrency control remains our responsibility for non-Filament writes.