Filament Undo Toast Laravel Package

Technical Evaluation

Architecture fit

• Laravel package distributed via Composer, registered as a Filament panel plugin. It extends Filament's action/notification surface rather than replacing it, and ships config, views and translations through the standard package service-provider pattern — a low-ceremony fit for any Filament-based admin panel.
• The undo model is "capture at delete time, replay on undo." v0.2.0 extends replay to related rows (HasUndoableRelations contract or ->restoreRelations([...])), covering BelongsToMany (with pivot columns), HasMany, HasOne, MorphMany, MorphOne, inserting only missing rows inside the same transaction. That is a meaningful capability jump: it moves the package from "undo a row" to "undo an object graph," which is where most real hard-delete regret lives.
• Front-end is an Alpine/JS toast stack layered on Filament's notification system. v0.2.0 replaces Filament's own success notification for the same action by default, with per-action and global opt-outs.

Integration feasibility

• Adoption cost is low: composer require, one plugin registration, opt-in per action. No queue, no external service, no schema change required for the base feature.
• Relation restore is opt-in and explicit — teams can ship row-level undo first and add graph restore later, per model.
• 23 shipped locales reusing Filament's own terminology (including correct Russian/Ukrainian/Polish/Czech plural forms) removes a translation project that most teams would otherwise absorb themselves.
• The Playwright E2E suite plus Testbench workbench app is a strong signal: the interactive parts (stacking, keyboard shortcut, focus handling, undo spinner, failure states) are the parts most likely to regress silently, and they are now covered.

Technical risk

• Pre-1.0 API instability. v0.x with a fast-moving surface (->replaceSuccessNotification(), ->restoreRelations(), new contract) means minor bumps can carry behavioural change. Evidence: v0.2.0 flips the default for success-notification replacement, which will visibly change every delete flow on upgrade.
• Hard-delete restoration is a data-integrity feature, not a UI feature. Risks: unique-constraint collisions if a replacement row was created during the undo window; FK ordering; cascade behaviour; restoring rows whose side effects (emails, files, search index, webhooks, audit trails) already fired and are not rolled back; and resurrecting stale child rows that were created before the delete. "Insert only missing rows" is sensible but means a partial graph can be restored.
• Long undo windows widen the drift window. The delete and the undo are in different transactions, so consistency depends on how long the undo entry lives and whether anything else touched the data.
• Payload retention and privacy. Deleted records are persisted somewhere to be replayable. That store now contains data the user believed was deleted — relevant for GDPR/DSAR, retention policies, and any tenant-isolation review.
• Filament coupling. Replacing Filament's success notification means the package tracks Filament's notification internals; a Filament minor release can break the override or double-notify.
• Bus factor. Single-maintainer package. Mitigants in this release: SECURITY.md, Dependabot with cooldown, SHA-pinned Actions, leaner dist archive.

Key questions

1. Supported matrix: Laravel and PHP versions, Filament v3 vs v4, Livewire version? Is Filament a hard or optional dependency?
2. Where is the undo payload stored, what is its TTL, is it encrypted, and how is it purged? Is it tenant-scoped?
3. Is undo authorized independently of delete? Can user B undo user A's deletion in a shared panel?
4. Which database drivers are tested in CI (sqlite, MySQL, Postgres)? Any known limitations for relation restore?
5. How are unique-constraint collisions and partial graph restores surfaced to the user?
6. What is the accessibility conformance target behind the High Contrast / screen-reader alert work — WCAG 2.1 AA?
7. Licence and roadmap to 1.0; is there a documented deprecation policy?

Integration Approach

Stack fit

• Best fit: Laravel + Filament admin panels where operators do destructive actions on records with real business value. Poor fit outside Filament, and unnecessary for append-only/soft-deleted domains where SoftDeletes already covers recovery.
• Complements rather than replaces SoftDeletes: use soft deletes where recovery is a workflow, use this where the product decision is a genuine hard delete but the operator needs a safety net.

Migration path (v0.1 → v0.2.0)

• Treat as a behavioural change, not a patch. Default-on replacement of Filament's success notification changes what every delete shows. Audit any successNotification() / successNotificationTitle() customisations — these are preserved — and any test that asserts on Filament notification content, which may now fail or double-count.
• Decide explicitly between global ->replaceSuccessNotification(false) and per-action closures. Recommendation: default off at the panel level, opt in per action, so the change is deliberate rather than inherited.
• If you maintain local translation overrides, verify precedence now that 23 locales ship in-package; the new locale-key/placeholder/plural test only validates the package's own files.

Compatibility

• Relation restore depends on your schema behaving: check FK constraints, ON DELETE CASCADE, unique indexes, and any DB triggers before enabling. Verify pivot-column coverage for BelongsToMany on tables with payload columns.
• Verify the transaction boundary composes with any outer transaction or job your delete path already runs inside.

Sequencing

1. Spike in a non-production panel; confirm Filament/PHP/Laravel matrix and that the toast stack renders correctly on your theme.
2. Enable row-level undo on one low-risk resource; validate the notification-replacement decision with real operators.
3. Decide and document the undo TTL and payload-retention policy; get sign-off from whoever owns data protection.
4. Audit FK/cascade/unique constraints on candidate models, then enable restoreRelations on one parent-child pair. Test the collision path deliberately.
5. Roll out panel-wide; add the package to the Filament-upgrade checklist and rely on the Playwright suite as an upgrade smoke test.

Operational Impact

Maintenance

• Small surface, but pre-1.0: pin exact versions and read every changelog. Budget recurring effort for Filament major upgrades, since the notification override is coupled to Filament internals.
• Supply-chain posture is now reasonable — SHA-pinned Actions, Dependabot with cooldown, SECURITY.md, slimmed dist archive. That shortens security review, but does not remove single-maintainer risk; consider a fork-and-patch contingency for a package this close to destructive operations.

Support

• Operator-facing change: deletes no longer double-announce, failed undos persist until dismissed and are announced as an alert. That is the right default for a destructive-action safety net — a silent failure is worse than a noisy one.
• 23 locales reduce internal translation tickets substantially; the shipped key/placeholder/plural test gives reasonable confidence, though it verifies structure, not copy quality.
• Document the undo window and its limits in operator docs. The most likely support ticket is "I undid it and it came back wrong / partially," which is a semantics question, not a bug.

Scaling

• Toast rendering is client-side and cheap; will-change is scoped to animation, no clip-path animation, and the stack no longer collapses on pointer gaps — all signs of performance-conscious implementation. No expected issues at normal admin concurrency.
• The scaling question is the undo payload store, not the UI. If entries persist to a table, add pruning/monitoring for growth; if they live in session or component state, undo is bounded by session lifetime — confirm which, because it changes the retention story and the failure modes.
• Relation restore is a multi-statement transaction; on large graphs, keep the undo window short and watch for lock contention on hot parent rows.

Failure modes

• Unique-constraint collision on restore → failed undo, surfaced as a persistent alert. Needs a documented operator recovery path.
• Partial graph restore (some children already re-created) → silently incomplete object. Highest-severity failure mode; test it explicitly.
• Filament upgrade breaks the notification override → duplicate "Deleted" toasts or a missing success signal.
• Undo entry expired or payload purged → action fails after the user was promised a safety net. Set the UI copy to match the real TTL.
• mod+z conflicting with browser/OS bindings, or firing while focus is in a text field. v0.2.0 widened the shortcut's focus scope to checkboxes, radios and buttons — verify it does not fire inside text inputs in your forms.
• Payload retained past a deletion request → compliance exposure, not a runtime error.

Ramp-up

• Developer ramp-up is hours: register the plugin, add the action modifier, optionally implement HasUndoableRelations. The contract is the only piece needing real thought.
• The genuine learning curve is conceptual, not syntactic: engineers must internalise that hard-delete undo does not reverse side effects, does not guarantee graph completeness, and is time-bounded. Put that in the ADR, not just the README.
• Operator ramp-up is near zero — the toast is self-explanatory, and stacked-toast interaction (tap to fan out on touch, front-toast tint preserved) is a deliberate usability investment. Pair it with one line of onboarding copy stating how long undo is available.