Filament Deleted Records Laravel Package

Technical Evaluation

Architecture fit

• amjadiqbal/filament-deleted-records is a Filament panel plugin that surfaces soft-deleted Eloquent records for review, restore, and permanent purge. It sits entirely inside the admin panel layer — no queue workers, no external services, no schema of its own beyond what Laravel's SoftDeletes already provides. That makes it a low-coupling addition: it can be added to one panel provider and removed without touching domain code.
• Fit is good if we already use SoftDeletes on the models we care about and already run a Filament 4/5 admin panel on Laravel 12/13. The package makes no claim of support for Laravel 11 or Filament 3, so anything older is out of scope.
• The real architectural weight is not the plugin — it is the authorization model it assumes. This release explicitly documents that without a policy or callback, any panel user can restore and purge. That is an application-level responsibility, and it means integration is really "plugin + a policy per soft-deletable model."

Integration feasibility

• Straightforward mechanically: Composer install, publish config, register the plugin on the target panel, define restore/forceDelete-style gates or the package's callback hook.
• Complexity is concentrated in two areas: (1) mapping roles to restore vs. purge rights across every soft-deletable model, and (2) confirming tenancy scoping actually constrains the listing query, not just the UI.
• The v1.0.1 search change is a behavioral change, not just a security patch. Any user workflow that relied on free-text search across arbitrary stored attributes will now return narrower results. Since we have no prior deployment, this is a non-issue for us — but it is a signal about the package's maturity.

Technical risk

• Secure-by-default gap (high). v1.0.0's search performed LIKE against the whole stored JSON payload, which allowed a panel user to confirm whether a masked value (e.g., a password hash) existed. v1.0.1 fixes this by matching on key exactly plus case-insensitive title attributes, and never a masked attribute. The fix is correct, but a leak of this class shipping in a 1.0.0 tells us the security review was not adversarial. Budget for our own review of config and query paths.
• Default-open authorization (high). The README now states plainly that absent a policy or callback, every panel user can restore and purge. This is honest, but it is a footgun. Purging is irreversible; treat the plugin as unsafe to enable before policies exist.
• Masking is presentation-only (medium). The docs now say so explicitly. Masked values are still materialized server-side and may reach the client depending on how the preview is rendered. Do not treat this plugin as a data-redaction control for PII or secrets.
• "Deleted by" is limited (medium). The release notes acknowledge limits. Expect gaps for cascade deletes, console/queue deletions, and historic records — so this column should not be used as an evidentiary audit trail.
• Bus factor (medium). Single maintainer, docs hosted on a personal domain, version 1.0.1. Small code surface limits blast radius, but there is no vendor SLA.

Key questions

1. How is the authorization callback resolved — per-model policy, per-panel gate, or a single global closure? Can it express "restore yes, purge no"?
2. Is tenancy scoping enforced at the query level or only by filtering the table? Can a crafted Livewire request escape the tenant boundary?
3. Are bulk restore and bulk purge transactional? What is the semantics when a batch partially fails (the release now separates permission-skips from failures — good — but is the rest atomic)?
4. Is there any audit event emitted on restore and purge, or must we log it ourselves?
5. Are masked attributes excluded from Livewire payloads, or only from rendered output?
6. Do MariaDB and SQLite behave equivalently to MySQL 9.7 / Postgres 17 for the new exact-key search path?
7. Is there a security disclosure policy and a commitment to patch timelines?

Integration Approach

Stack fit

• Requires PHP 8.3–8.5, Laravel 12/13, Filament 4/5. Confirm our panel version before committing; a Filament 3 or Laravel 11 panel rules this out entirely.
• Database support verified on MySQL 9.7, Postgres 17, and SQLite via DB_TEST_DRIVER. If we run MariaDB or an older MySQL, treat that as unverified.

Migration path

• No data migration. The plugin reads existing soft-deleted rows. The only prerequisite is that target models already use SoftDeletes and that their deleted_at columns are indexed.
• Because this is net-new capability, "rollback" is simply disabling the plugin in the panel provider — but any purges performed are unrecoverable, so rollback of the code does not roll back the data.

Compatibility

• The v1.0.1 search change narrows result sets. With no existing users this costs us nothing; if we had an earlier pilot, we would need to re-brief admins.
• New test coverage across MySQL/Postgres is a meaningful maturity gain versus the implied SQLite-only validation earlier.

Sequencing

1. Spike (non-prod). Install on a staging panel, point at a copy of production data, verify listing, tenancy, and preview behavior for our highest-sensitivity model.
2. Authorization first. Define policies/callbacks for every soft-deletable model before any user sees the feature. Separate restore from purge. Deny purge by default.
3. Restrict audience. Enable for a super-admin group only; no general panel access in the first release.
4. Observability. Add our own audit logging around restore and purge actions, since the plugin's "Deleted by" is not authoritative.
5. Broaden. Extend restore-only rights to support/ops roles, keeping purge behind a named approver group.
6. Review cadence. Re-evaluate on each release; pin the exact version in composer.json.

Operational Impact

Maintenance

• Low code footprint, but this is a 1.0.1 package with a security fix already in its history. Pin the version exactly and subscribe to releases; do not float a ^1.0 constraint on a package whose patch releases can change search behavior.
• Plan to own a thin internal wrapper (policy classes, config) so a fork or replacement is a contained change rather than a panel-wide rewrite.

Support

• Single maintainer with docs on a personal domain — acceptable for an internal admin convenience tool, not for anything customer-facing or compliance-scoped.
• We will need an internal runbook: who may purge, how to request it, and what to do when a purge was wrong (answer: restore from backup — the package offers no undo).
• Escalation path for bugs is essentially GitHub issues. Budget engineering time to read the source rather than wait on upstream.

Scaling

• Listing deleted records is a table query against tables that may be large precisely because nobody has purged them. Ensure deleted_at is indexed; watch for panels where the deleted-record count reaches six figures.
• Removing the LIKE-over-JSON search is a performance win — the old path could not use indexes and scanned the full stored payload per row. Exact-key matching is cheaper.
• Bulk purge of large batches is a destructive, potentially long-running operation in a web request. Validate batch size limits and consider whether large purges should be an out-of-band job.

Failure modes

• Irreversible purge by the wrong user — the dominant risk, caused by the default-open authorization. Mitigated only by policy work done before enablement.
• Sensitive value disclosure — the v1.0.1 search vector is closed, but masking remains presentation-only, so any export, API surface, or client-side payload could expose raw attributes.
• Partial bulk operations — v1.0.1 now reports permission-skipped records separately from failed restores, which is a real usability improvement, but operators must still read the report rather than assume success.
• Misleading "Deleted by" — deletions from console commands, seeders, or cascades will not attribute correctly, which can send investigation down the wrong path if treated as an audit record.
• Tenancy leakage — if scoping is UI-level rather than query-level, a panel user could enumerate another tenant's deleted records. Verify before enabling on any multi-tenant panel.

Ramp-up

• Developer effort: hours to install and configure; days to write and test policies across all soft-deletable models.
• Admin effort: low — the UI is conventional Filament. The training burden is procedural (purge is permanent, purge is privileged), not technical.
• Recommend a written internal policy statement alongside enablement, given the README's explicit warning that defaults are permissive.