Nova Toggle 5 Laravel Package

Product Decisions This Supports

• In-admin state changes without custom tooling: this package adds a toggle endpoint/control for boolean attributes on Nova resources, so PMs can ship "flip this flag from the admin" workflows (publish/unpublish, feature enablement, active/inactive) as configuration rather than bespoke controller + UI work.
• Build vs. buy on internal admin tooling: when the roadmap includes admin-side operations on Laravel models, the decision is usually "extend Nova" vs. "build a separate back-office." A small, single-purpose package like this lowers the marginal cost of staying on Nova.
• Operational workflows over trashed data: this release makes the toggle usable from "With Trashed" and lens views that surface soft-deleted rows. That unlocks support/ops use cases — restoring, quarantining, or re-activating a deleted record — without a database console or tinker session, which is a real reduction in ops escalation and engineering interrupts.
• Audit and permission posture: authorization and the toggleable-attribute whitelist apply to trashed records too, so the fix does not open a side door around policy checks. That supports decisions to expose destructive-adjacent actions to less technical staff.
• Maintenance-cost signal for the dependency portfolio: the package is patched promptly by a contributor with a drop-in upgrade and no migration. That is a favorable input when deciding whether to keep a thin third-party dependency versus forking internal code.

When to Consider This Package

Consider it when:

• The stack is Laravel Nova 5 and the admin panel is already the system of record for a boolean flag.
• The flag lives on a model where soft deletes are in play and staff need to act on trashed rows from "With Trashed" or lens views — the exact case this release fixes.
• You want the change to go through Nova's authorization policies and a whitelist of toggleable attributes rather than a hand-rolled endpoint.
• You value a small, single-responsibility dependency with drop-in upgrades over bundling this behavior into application code.

Look elsewhere when:

• You are not on Nova 5, or you are planning a move off Nova — the value is bound to that UI and its endpoint conventions.
• The action needs to be transactional with other domain effects (notifications, ledger entries, state machines). A toggle endpoint flips a boolean; richer transitions belong in application services or a Nova Action with explicit logic.
• You need bulk toggling, scheduling, or an audit trail beyond what Nova's own activity tooling provides.
• The flag is customer-facing and latency- or consistency-sensitive; admin-panel toggles are not a substitute for a proper feature-flag service.

How to Pitch It (Stakeholders)

For executives: this is a small, low-risk dependency that lets support and operations staff change a record's on/off state directly in the admin panel instead of filing an engineering ticket. The new patch fixes a real gap — staff could not toggle records that had been soft-deleted, so "restore/reactivate this deleted item" work fell back to engineers. It is a drop-in composer update, no migration, no breaking change, and permission checks still apply to trashed records, so there is no widening of who can do what. Net effect: fewer interrupts for engineering and faster turnaround on a recurring operational task, at effectively zero integration cost.

For engineering: v1.3.1 applies withTrashed() to the toggle lookup when the Nova resource uses soft deletes, resolving the 404 that made the endpoint unusable from "With Trashed" and lens views. Behavior is unchanged for resources without soft deletes, and both the authorization check and the toggleable-attribute whitelist continue to run against trashed records. Upgrade path is composer update almirhodzic/nova-toggle-5; no code changes required. Worth adding a regression test in our own suite covering a toggled soft-deleted model from a lens view, since that is the path our ops team will actually use.