Product Decisions This Supports
- Build vs. buy for admin recovery tooling. This is a small, single-purpose Filament plugin that adds a "deleted records" surface for soft-deleted models (browse, restore, permanently delete, bulk actions). If we are currently hand-rolling a restore/purge screen or running ad-hoc
tinker/SQL to recover deleted rows, this is a cheap way to close that gap. If we have no soft-deletes in the domain, it is irrelevant.
- Go/no-go on adoption, with conditions. v1.0.1 fixes an information-disclosure bug (search previously matched the entire stored JSON blob with
LIKE, so a user could confirm a masked value — e.g. a password hash — by probing for it). Any evaluation of v1.0.0 should be discarded; assess only v1.0.1+.
- Authorization design is a prerequisite, not a nice-to-have. The README now states plainly that without a policy or callback, any panel user can restore and purge. That is a destructive-operation default of "allow." Adoption is only defensible if we pair it with a policy in the same PR — this is a product decision about who in support/ops can destroy data, not just a config detail.
- Data-handling expectations. Masking is on screen only — values remain in plaintext in the database and the plugin does not redact. Do not let this ship into a context where someone believes the preview is a compliance control; it is a shoulder-surfing mitigation at best.
- UX tradeoff to accept explicitly. Search semantics changed: it now matches keys exactly and title attributes case-insensitively, and never a masked attribute. Users who expected "search any value inside the deleted record" (e.g. find the deleted order by the customer's email buried in a JSON column) lose that. Expect a small wave of "search doesn't find it anymore" tickets; decide whether to communicate or extend.
- Operational clarity for bulk actions. Bulk restore / permanent delete now report permission-skipped records separately from failed restores. That maps directly to support workflows — an operator can distinguish "I'm not allowed" from "this one is broken" without reading logs.
- Roadmap gaps this surfaces for us (not in the package): no audit trail of who restored or purged what, no scheduled retention/purge policy, no per-record granularity beyond Laravel policies, and "Deleted by" has documented limits. If any of those are requirements, budget for them separately or treat this as UI only.
When to Consider This Package
Consider it when:
- You use Filament 4 or 5 on Laravel 12/13, PHP 8.3–8.5, and your models use
SoftDeletes.
- You need an in-panel recovery path for support/ops staff so engineers stop fielding "can you undelete this?" requests.
- You are willing to write and review a policy (or callback) before enabling it, and to restrict the panel/resource to trusted roles.
- Your stack is MySQL or Postgres (now covered via
DB_TEST_DRIVER, tested on MySQL 9.7 / Postgres 17 / SQLite). SQLite-only shops are fine too.
- You accept that this is a v1.0.x, single-maintainer package with docs on a personal domain — appropriate for internal admin tooling, not a critical-path dependency.
Look elsewhere or build in-house when:
- You need audit-grade logging, immutable restore/purge history, or compliance reporting — this does not provide it, and masking being display-only means it is not a redaction tool.
- You need retention policies or scheduled purge (e.g. GDPR erasure windows) — that is application logic you own.
- Your authorization model needs record-level scoping beyond what a policy can express, or your tenancy model is non-standard — verify tenancy behavior against your own setup first; the README "covers tenancy," which is a description, not a guarantee.
- You are on Filament 3, older Laravel, or PHP < 8.3.
- Any part of the flow is customer-facing. The "any panel user can purge by default" posture and the recent search-leak bug make this an internal-tools-only bet until it has more time in the field.
How to Pitch It (Stakeholders)
To executives: We are evaluating a small open-source add-on that gives support staff a safe, permissioned screen to restore accidentally deleted records instead of filing engineering tickets. It is low cost — a Composer dependency, no vendor contract — and it removes a recurring manual, error-prone task. Two caveats drive the recommendation: the release we would adopt (v1.0.1) fixes a security bug where search could reveal masked values, so we adopt that version or nothing; and by default the plugin lets any panel user permanently delete data, so we will gate it behind an explicit permission policy before it goes live. Estimated effort is small but not zero: policy work plus a role restriction. Recommended as an internal admin tool, not a customer-facing feature.
To engineering: Pin ^1.0.1 — do not ship 1.0.0, which allowed LIKE-probing of masked attributes via search. Before enabling the resource: add a restore/forceDelete policy (default is allow-any-panel-user), confirm the new search semantics (exact key match + case-insensitive title attributes, masked attributes never matched) don't break any workflow we've promised, and note that masking is presentation-only — the underlying columns are untouched. Bulk actions now separate permission-skips from failures, which is useful for support triage. It is v1.0.x from a single maintainer with a CI matrix (23 Pest tests, PHPStan, Pint, headless-Chrome checks across Laravel 12/13 and Filament 4/5, MySQL/Postgres/SQLite) — reasonable hygiene, thin bus factor. Wrap it behind our own resource/permission boundary so swapping it out is a contained change, and if we need restore/purge audit history or retention automation, scope that as our work, not theirs.