Nova Detached Actions Laravel Package

Product Decisions This Supports

• Shipping internal admin features faster. The package does one narrow thing: it moves a Nova action's trigger from the row-selection checkbox into the resource toolbar. That single change turns imports, exports, report generation, cache/search-index rebuilds, and one-click maintenance into buttons on admin screens we already own — no bespoke page, no custom card, no new navigation. For back-office tooling, the lever is time-to-ship measured in days rather than sprints.

• Reframing build vs. buy honestly. The package is a thin presentation layer over Nova's own Action class, field definitions, modal lifecycle, and authorization contracts. "Buy" is defensible on effort, but given it was last released in October 2020 and the upstream repo is archived, the accurate decision record is vendor a small MIT utility and own it — "adopt, fork, and maintain," not "add a dependency." The permissive license is what makes that middle path cheap and legitimate.

• Reuse over rebuild. Existing action classes, fields, confirmation modals, and authorizedToSee / canRun gating all work unchanged. An ExportAction written for row selection can become a workspace-level command with no new domain code and no second permissions model. That is velocity without accumulating architectural debt.

• Drawing an explicit scope boundary. It changes where a trigger lives, not what it does. It is not a workflow engine, scheduler, audit log, or job runner. Any roadmap item needing approvals, retries, run history, or "did it actually run?" observability still requires a queue and durable logging behind the button. Stating this now prevents a mid-build surprise.

• Treating roadmap risk as a version bet. A 2020-frozen package is pinned to the Nova major of its era. If a Nova upgrade appears anywhere on the roadmap, this package becomes a migration cost line, not a feature — and that tension belongs in roadmap review today, not discovered at upgrade time.

• Managing risk per action, not per package. The package installs once; the value and the blast radius are per action. Product decisions should be made action by action: which commands get a toolbar button, visible to which roles, with what confirmation step. Detached actions bypass the checkbox gate, so a registration mistake can expose a maintenance command to the wrong audience.

• Reading ecosystem signal correctly. 164 stars, zero dependents, middling quality score, archived: a niche, low-blast-radius tool with no community to lean on for fixes. Fine as internal plumbing. Not a product narrative and not a signal of strategic value.

When to Consider This Package

Consider adopting when:

• We are a licensed Laravel Nova shop on the major version this was built against (circa Nova 2/3). This is the gating question — resolve it before any other evaluation. Nothing else matters if the answer is no.
• The need is internal and back-office: ops consoles, admin panels, data imports/exports, report triggers. Low design differentiation, no customer-facing surface.
• The team already authors Nova actions and wants them usable as standalone commands without a checkbox step or a hand-rolled toolbar card.
• Time-to-ship outweighs long-term support, and engineering is comfortable forking an MIT package and naming an owner for it.
• The detached-action inventory per screen is modest — a handful of buttons, not thirty. The overflow menu and registration-order behavior handle modest growth, but that is a 2020-era UX decision inherited as-is.

Look elsewhere when:

• We are on Nova 4/5 or plan to be. An archived 2020 package will not track newer Nova front-end, PHP, or Laravel requirements, and no maintainer is returning. Treat current-major support as an unverified spike, never an assumption.
• We need active maintenance, security review, or a vendor support contract. There is none and there will not be one.
• The actions require auditing, approvals, scheduling, or observable background execution. Nova actions execute at request time; pair with a queue and durable log, or build a proper tool.
• A small custom Nova tool or toolbar partial would do the same job in code we already control. The surface is narrow enough that "build" is a credible answer — the delta may be a few dozen lines of registration and a Blade partial.
• The admin surface is a competitive differentiator, or it needs an interaction model the default action layout cannot express.
• We are not on Nova at all — this is inert for Filament, Inertia/SPA front ends, or custom admin builds.

How to Pitch It (Stakeholders)

To executives. This is a small, MIT-licensed tool that lets our admin panel run commands — imports, exports, reports, maintenance — without users selecting rows first. It reuses Nova's existing action and permission model, so build effort is low and the security story is inherited rather than invented. The caveat is lifecycle: it is archived upstream and has shipped no release since 2020. That makes it a vendored utility, not a strategic dependency. Recommendation: use it on internal ops screens where it measurably saves operator time, keep it off anything customer-facing, and budget a fork-and-own contingency — the permissive license makes that inexpensive. If a Nova upgrade is on the roadmap, price this package into that migration now rather than later.

To engineering. Adopt it as a pinned, vendored, first-party dependency rather than a live remote package. Step one is the only real unknown and it is disqualifying if it fails: verify compatibility against our Nova, PHP, and Laravel versions, and validate the asset pipeline — a stale compiled bundle is the most likely silent failure, where buttons render but clicking them does nothing. Then write a test proving a user without the policy ability can neither see nor execute a detached action; that single test is the whole security story. Guard handle() explicitly for the empty-model case, since detached invocations receive no selected records, and queue anything slow. Treat registration array order as a deliberate UI decision — the first registered action sits nearest Create. Keep row-specific actions behind checkboxes and resource-wide commands detached, and don't register the same action in both places unless its handle() genuinely behaves for zero models and n models alike. Finally, name an owner and put a compatibility review on the calendar alongside every framework upgrade, so the next Nova bump is a diff rather than an archaeology project.