Nova Action Buttons Laravel Package

Product Decisions This Supports

• Converting "we need an admin button for X" requests into shippable scope. The core decision this package unlocks is turning backlog items like "let ops refund/fulfill/retry/resend from the admin table" into days of work instead of a frontend sprint. Any existing Nova action becomes a one-click button with a confirmation dialog — no Vue, no custom tool, no new controller. That shifts a whole class of admin requests from "engineering project" to "config change."

• Build vs. buy for admin UI. The real comparison is adopt this field vs. build an in-house Nova custom tool/card. For standard button-triggered actions with confirmation modals, adoption wins decisively on cost and time-to-ship, and ongoing maintenance is a config file rather than a component library. Switch to build only when the workflow needs multi-step forms, wizards, or bespoke layouts the package can't express — or when the action is load-bearing enough that single-maintainer risk is disqualifying.

• Nova 5 upgrade as a gated milestone. v2.x is the Nova 5 compatibility line, so this is effectively a dependency gate on "upgrade the admin panel to Nova 5." Either it's compatible or it blocks the milestone. Track it explicitly in upgrade planning rather than discovering it during rollout.

• Prioritization signal for which workflows to convert first. Best ROI goes to features where a per-row button plus confirmation modal replaces a support ticket or an "ask an engineer to run an artisan command" request: order management (refund/fulfill), support consoles (escalate/close), content moderation (approve/reject), finance ops (re-run sync, resend invoice).

• Risk acceptance for a small dependency. ~15 stars, zero dependents, single maintainer, MIT. Zero dependents means essentially no external production validation — we'd be an early adopter, not a follower. That's a legitimate decision to make deliberately for internal tooling, and a legitimate decision to decline for revenue-critical back-office flows without a fork-or-vendor contingency.

• Not a decision driver: v2.0.1 carries no new capability. It is byte-identical to v2.0.0, re-cut from cleaned-up main history. Do not schedule work against "2.0.1 features" — there are none, and no fixes are included either. Treat v2.0.0 as the meaningful event and 2.0.1 as housekeeping.

When to Consider This Package

Adopt when:

• You are on Laravel Nova 5 and need per-row action buttons that preserve Nova's native authorization (canSee/canRun), visibility scoping (onlyOnIndex/onlyOnDetail), modals, and confirmation dialogs.
• The admin panel is internal-facing and the team has limited frontend capacity — config-driven buttons beat a hand-rolled Nova tool on ongoing maintenance cost.
• You want a small, single-purpose dependency rather than a broad admin framework; the surface area is a couple of files, and MIT keeps the fork option open.
• You need a pilot-scale win: one resource, one workflow, days of effort, measurable outcome.

Look elsewhere / deprioritize when:

• You are on Nova 3 or 4. v2.x targets Nova 5, and mixing a v2 package with an older Nova fails at render time (class-not-found, signature errors), not at install time — an expensive debugging mode.
• Native Nova actions already satisfy the workflow (select rows → run action). A second interaction paradigm has real cognitive cost for admins and should be justified by frequency or urgency.
• You need complex forms, wizards, or non-Nova surfaces (public UI, customer portal) — build a custom tool or a proper frontend.
• Maintainer risk is unacceptable for the use case. Fine for internal tooling; require a named fork-and-patch owner before making it load-bearing for revenue-critical flows.
• You are already on 2.0.0 — 2.0.1 changes nothing; skip it entirely.

Answer these cheaply before committing budget: what exactly changed in v2.0.0 (minimum Nova/PHP/Laravel floors, renamed or removed APIs, documented v1 → v2 migration); whether there are automated tests running against multiple Nova 5 patch releases; whether the package honours onlyOnIndex/onlyOnDetail, lenses, relationship indexes, and per-row canSee; the maintainer's release cadence and issue-triage responsiveness over the last 12 months; and whether it ships publishable views/config (which determines the override upgrade story). Each materially changes the risk profile.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk addition to our internal admin toolkit that lets us ship row-level operator workflows — refunds, approvals, retries, moderation — in days instead of weeks of custom frontend development. Operators click a button on the row instead of filing a ticket; engineering stops being a queue for one-off admin tasks. The meaningful event is v2.0.0, which brings Laravel Nova 5 support and is therefore a prerequisite gate on our admin-panel upgrade. v2.0.1 is a housekeeping re-release with no code changes — no new capability, no new risk, no new cost. It's MIT-licensed and small, which means we can fork it if the maintainer disappears. Recommendation: approve adoption for internal admin panels on Nova 5, scoped to a single pilot workflow with a named owner and a named fork contingency, and revisit for broader rollout once the pilot produces numbers (time-to-action, tickets absorbed, admin error rate, index render time).

For engineering: composer require pavloniym/nova-action-buttons on Nova 5 apps; pin ^2.0. v2.0.1 and v2.0.0 are the same files — the patch bump is purely a history cleanup from main, so no migration note is needed and no fixes are included. Read the v2.0.0 changelog for the real Nova 5 breaking changes (minimum Nova/PHP versions, renamed button APIs) before rolling across multiple apps, and never upgrade this package independently of Nova. Integration is deliberately minimal: leave existing Action classes untouched, keep canSee/canRun/confirmText on the action class rather than in view conditionals, and change only where actions are declared — a shared toolbar for global actions, fields() for row-scoped lifecycle actions. Watch two things in review: per-row authorization cost (each button is an action Nova authorizes per row — six buttons on a 50-row index is roughly 300 policy evaluations per page load, fine until canSee hits the database or an API) and double-submit (a visible button is a larger click target than a dropdown item, so idempotency belongs in handle(), owned by the application, not the package). Keep it out of anything customer-facing, validate against the exact Nova patch version in production rather than "Nova 5" generically, and diff any published Blade overrides against vendor/ after every upgrade.