Inline Boolean Laravel Package

Product Decisions This Supports

• Whether inline boolean editing earns a spot on the admin UX roadmap. The decision this package informs is whether one-click toggles for published, is_active, featured, verified, or suspended are worth dedicated investment versus routing ops users through the full edit form. Inline editing removes clicks and page loads from high-frequency tasks, but it is a UX bet — and this is a cheap way to prototype the interaction, put it in front of real ops users, and measure time-to-update and clicks-per-task before committing engineering time to a first-class feature.
• Build vs. buy vs. native — this is a reference implementation, not a vendor bet. Seeing the pattern work in a spike answers a concrete roadmap question quickly: does our current Nova major already do this natively (close the ticket), can we build a ~1–2 day in-house field, or do we need to fork? The package supplies a working demo that makes that call cheap. It should be scored as research input, not as a dependency we adopt.
• Which operational workflows deserve a quick-action surface. Moderation and approval queues, catalog/storefront visibility, publish states, account suspension, and lightweight feature flags are the workflows where PMs and ops teams change status constantly without needing to open a record. Use the package as a lens to rank those workflows by how much a one-click toggle is actually worth — and by how bad a mistaken click would be.
• Governance and permissions — a product decision disguised as a technical one. Inline editing writes data outside the normal resource update form, so the usual validation and audit trail may not apply. PMs must classify which booleans are safe for one-click toggling versus which require confirmation, audit logging, granular permissions, or the full form (e.g. "cannot unpublish an already-invoiced item"). That classification determines whether this ships as an everyday convenience or stays gated to an admin role.
• Standardization across resources. If the pattern proves valuable, it seeds an internal Nova field library with one toggle behavior, one authorization model, and one set of guards — instead of six bespoke implementations drifting across teams.
• Adoption policy for unmaintained dependencies. A single release, zero stars, zero dependents, no CI, no changelog, and a committed prebuilt JS bundle is a live test case for the org's stance on frozen packages. Using it to inform a decision is defensible; quietly shipping it to production sets a precedent worth being deliberate about.
• Scope reality check. Note the mismatch between the marketing description ("Blade component, configurable AJAX endpoint") and the implementation (a Nova field bundled for Nova 2/3-era Vue). Practically, this is an admin-panel-only capability — it does not create a reusable inline-toggle primitive for customer-facing Blade views. Any roadmap item assuming the latter needs a different solution.

When to Consider This Package

• Consider it if you run Laravel Nova on a Nova 3-era stack (Laravel ~6–8, PHP 7.2–8.0), you genuinely need inline boolean toggling in the admin, and you are prepared to vendor or fork the source — because there is no upstream support path. In that narrow case it is a one-to-two-day head start on a known pattern.
• Check the native baseline first. Confirm whether your current Nova major already supports inline boolean editing on index and detail views. If it does, the package is redundant and the decision is already closed — spend the budget elsewhere.
• Treat it as a spike, not a dependency. The right frame is a non-production prototype in a throwaway container to confirm the field class resolves, the compiled JS bundle actually mounts, and the click hits Nova's own policy-checked field-update endpoint. That answers most of the risk for almost no cost.
• Look elsewhere — or build — if you need any of: a maintained dependency with security updates, audit logging, field-level permissions enforced server-side, validation and business-rule invariants, optimistic UI with rollback, localization, multi-tenant scoping, or Nova 4/5 and PHP 8.2+ compatibility. Nova 4's move to Vue 3 + Vite restructured the field component contract, so a 2020 compiled bundle will almost certainly fail to register, and the 2020-era Composer constraints will hard-fail resolution on modern PHP. Forcing it with --ignore-platform-reqs is not an acceptable workaround — if the constraint is wrong, the bundle is wrong too.
• Non-negotiable adoption gate: verify whether the toggle routes through Nova's policy-checked field-update endpoint or ships its own controller and route. If it bypasses authorizedToUpdate, a list-view toggle is an authorization bypass — that alone disqualifies it for production without a fork and a negative-permission test.
• Silent-failure check: confirm what the UI does when the server rejects a write (403/422). An optimistic toggle that shows green after a failed save is worse than no feature — it creates false confidence in moderation and publishing data.

How to Pitch It (Stakeholders)

To executives (30 seconds): Ops and support staff spend real time opening records just to flip a status. This package is a free, working prototype of one-click status toggles in our admin panel — we can put it in front of users for a few days and get a concrete read on whether the interaction is worth building properly. It is explicitly not a production dependency: it is unmaintained since 2020, has no security or upgrade path, and only works on our older admin stack. The recommendation is a timeboxed spike to validate the workflow, followed by a build-or-native decision — expected cost of the real feature is one to two engineer-days if we own it.

To engineering (the ask): Spin it up in a throwaway container against a Nova 3-era app and answer three questions in an afternoon: (1) does the compiled Vue bundle mount at all, (2) does the click POST to Nova's built-in policy-checked field-update endpoint rather than a package-owned route, and (3) does the UI roll back on a rejected write. If any answer is no, we do not adopt — we scaffold our own field (nova:field) and reuse the interaction pattern, not the code. If we somehow do proceed with the original, it gets vendored into our own nova-components/ package, pinned by commit SHA, covered by a negative-permission test ("user without update rights cannot toggle"), and logged via a model observer so we can answer "who flipped this, and when" during an incident.

Bottom line: high learning value, low production viability. Fund the spike, not the dependency — and treat the outcome as either "build it ourselves" or "our Nova version already does this."