Filament Recycle Bin Laravel Package

Technical Evaluation

Architecture fit. The package is a Filament panel plugin, not a domain-layer library: it registers a single panel page that aggregates trashed records across a configured set of Eloquent models and exposes restore / force-delete actions from one screen. Architecturally it sits entirely in the presentation layer, which is the right place — it imposes no runtime footprint on the request path outside the panel, and it requires no changes to existing models beyond their already using SoftDeletes.

The design is registry-based (a config list of model classes) rather than trait-discovery. That is a defensible trade-off — predictable, explicit, no reflection magic — but it introduces a silent-gap failure mode: any soft-deletable model not added to the config is invisible in the bin, so the page's usefulness degrades quietly as the schema evolves. Assume a coverage test is needed regardless of what the package ships.

The genuine value proposition is the centralized cross-model view. Filament resources already offer a per-resource trashedFilter; what they don't offer is one place for a support analyst or data steward to answer "where did this record go, across the whole app?" That's an ops-workflow win, not a developer-ergonomics win — size the business case accordingly.

Integration feasibility. Low for the happy path, and gated hard on the unhappy ones.

• Effort (greenfield, Filament v5, SoftDeletes already present): XS–S — a few hours. composer require, register the plugin in the PanelProvider, publish the config, enumerate models, wire a page gate.
• Hard gate: the Filament v5 constraint. Most estates are on v3/v4. This package is only viable for greenfield or early-adopter panels, which materially shrinks the addressable benefit.
• Prerequisite workstream: if models don't already use SoftDeletes, adding deleted_at to large tables is a separate migration project (online DDL, index build cost), not a plugin install.
• Validation: 11 stars and 0 dependents means zero external production validation. We would be the first adopter. Treat this as evaluate-and-probably-fork, not adopt.

Technical risk (ranked).

Key questions to answer before commitment.

1. Does force delete enforce per-model policies, or a single page-level gate? (Read the source, don't trust the README.)
2. How is tenancy applied to the aggregate query — explicit tenant filter, global scope inheritance, or neither?
3. Is model registration config-only or trait-discovered? What is the behavior for an unregistered soft-deletable model?
4. How are display labels resolved for arbitrary models, and is that overridable per model?
5. Pagination/search strategy: per-model query then in-memory merge, or SQL UNION? What happens at 100k trashed rows?
6. Does force delete fire forceDeleting so existing observers handle file/relation cleanup?
7. What are the exact Composer constraints (Filament, Laravel, PHP, Livewire), and how promptly is a Filament release tracked?
8. Is there a runnable test suite we can point at our own models?

Recommendation: conditional spike, 1–2 dev-days. Do not take a production dependency until tenancy scoping and policy delegation are verified by source review and a test against our own models. Budget for a vendored fork from the outset.

Integration Approach

Stack fit. Laravel 11/12 + Filament v5 panel + PHP 8.2+. It occupies the admin-panel layer only. No impact on domain code, jobs, or API surface, and no effect on any consumer that doesn't render the panel page — which makes it cheap to feature-flag and cheap to remove.

Migration path. Three distinct starting positions:

• On Filament v5 with SoftDeletes in place: direct install. Publish config, list models, register the page in the panel's navigation group, restrict visibility behind a permission.
• On Filament v3/v4: blocked. Do not upgrade Filament to obtain a recycle bin. Either build an equivalent page in-house (est. 3–5 dev-days using the same registry pattern) or accept per-resource trashedFilter plus a manual admin runbook.
• Models not soft-deletable: separate workstream. Additive nullable deleted_at + index migration per table, online DDL for large tables, then opt models in one at a time behind the registry.

Compatibility. Verify the package's Composer constraints against our locked Filament/Livewire versions before anything else. Then check for interference with: Filament's built-in tenancy, any audit-logging package (force deletes must land in the audit trail, not bypass it), and other plugins that add panel pages or override table behavior. Theme/navigation collisions are cosmetic but will generate support tickets.

Sequencing.

1. Inventory every model using SoftDeletes, its policy, and its tenancy posture. (Day 1)
2. Spike in a scratch panel against 3 representative models: one tenanted, one with a unique constraint, one with polymorphic media. (Day 1–2)
3. Source review of the aggregate query and authorization path. (Day 2)
4. Decision gate: adopt as-is / fork-and-harden / build in-house.
5. If proceeding: RBAC design (who sees the bin, who may force delete), audit hook, retention policy.
6. Pilot with support/ops on non-critical models only, then expand the registry.
7. Add deleted_at index verification and a scheduled purge job before rollout completes.

Operational Impact

Maintenance. The dominant recurring cost is tracking Filament majors. Pin exact versions, watch releases, and budget ~0.5–1 day per Filament minor for regression verification if forked. Registry upkeep is the quiet tax: add a test asserting every model using SoftDeletes appears in the config, otherwise the bin silently loses coverage over time.

Support. No vendor, no community, no dependents to lean on. This requires named internal ownership: a code owner, a fork living in our VCS, and a short runbook. Expect two recurring ticket classes — "why can't I see the deleted record for X" (registry gap) and "restore failed" (unique-constraint collision).

Scaling. Trash grows monotonically unless something purges it. Required before production: a deleted_at index on each soft-deletable table, verified pagination behavior, and a scheduled retention job (e.g. force-delete older than 90 days) that writes to the audit log. The cross-model listing is the bottleneck; if p95 page load exceeds ~2s, split the page by model group or move bulk export async.

Failure modes.

• Cross-tenant visibility or unauthorized force delete → data-loss incident. Mitigate with policy and tenancy tests in CI, not manual QA.
• Force delete blocked by FK constraint → user-facing 500 with no guidance. Mitigate with a pre-flight dependency check and a clear error message.
• Restore violating a unique index → exception, record stays trashed, user retries and fails again. Mitigate by catching and surfacing the conflict with a rename option.
• Orphaned files / polymorphic media after force delete. Mitigate by confirming forceDeleting observers run, plus a periodic cleanup job.
• Silent registry gap → records practically unrecoverable. Mitigate with the coverage test above.
• Filament upgrade breaks the page → whole admin panel degrades to 500. Mitigate with version pinning, staging verification, and a config flag to conditionally register the plugin.
• Package abandonment → fork contingency. Mitigate by keeping the fork building in CI from day one.

Ramp-up. Developers: under an hour — it's a conventional Filament plugin with a familiar registration pattern. Support/ops users: ~30 minutes, but pair it with a written destructive-action policy (confirmation step, and ideally a second approver for force delete). SRE needs to know two things: where the retention job lives and where the audit trail is. Learning cost is negligible; the real cost is governance, and that cost is entirely on us, not the package.