Inline Boolean Laravel Package

Product Decisions This Supports

• Admin/back-office UX investment: This package targets a narrow but real workflow gap — toggling a boolean (published, active, featured, verified, enabled) straight from a Nova resource index or detail page instead of opening the full edit form. It supports the decision of whether "one-click state changes" in internal tooling are worth dedicated engineering time.
• Build vs. buy for Nova fields: At 16 stars, last shipped June 2019, and now archived, this is not a "buy" in any commercial sense — it is a fork-or-replicate decision. The functional surface is small enough that the honest comparison is "vendor this ~100 lines" vs. "spend 1–2 dev days writing our own field."
• Roadmap input for internal tooling: If ops/support/content teams complain about click-depth for moderation or catalog toggles, this is a candidate for a small, time-boxed initiative. Success metric is concrete: clicks-per-task and time-to-toggle on high-frequency admin actions.
• Use cases it fits: moderation queues, catalog/pricing enablement, internal feature/config flags, entitlement or account-status toggles in support consoles — all cases where the record's other fields don't need editing at the same time.
• Risk-register entry: Adopting it creates a knowingly unmaintained dependency in the admin tier. That is a decision to record explicitly, not to let drift in via a composer require.
• Signal, not a solution: The low composite score (1.44) and low opportunity score (1.86) in the sourcing rubric point the same direction as the archive flag — the pattern is valuable, the artifact is not. Use this evaluation to justify building the capability in-house rather than to justify adoption.

When to Consider This Package

Consider it only when all of the following hold:

• You are on the Laravel Nova generation this was built for (2.x/3.x era) with a matching PHP version, and you have no near-term upgrade path forcing a rewrite anyway.
• The surface is internal admin only — no customer-facing UI, no revenue-critical flows depending on the toggle.
• You are prepared to fork and vendor the code, pin it, and own it; treat it as a code sample, not a dependency.
• The requirement is exactly "flip a boolean in place," with no audit trail, approval workflow, or confirmation dialog needed.
• You have read the source. It is small enough that a 30-minute review is a realistic gate.

Look elsewhere — or build — when any of these are true:

• Nova 4/5 or PHP 8+: an archived 2019 package is very unlikely to be compatible, and you should not be the one to find out in production.
• Auditability or compliance matters: who toggled what, when, and from where is a common requirement for any state-changing admin action. This package does not give you that; a controlled edit flow or your own implementation with logging does.
• Authorization granularity matters: per-field or per-record toggle permissions, or toggles that should be blocked based on record state.
• Concurrency or UX polish matters: optimistic UI, race conditions between two admins, accidental-click protection, keyboard/screen-reader accessibility.
• You want ongoing maintenance: no tests, no releases since 2019, no issue triage.
• Cost of replication is low: a minimal custom Nova field covering the same interaction is a well-understood pattern. If your team can build it in under two days, buying an abandoned package is the more expensive option once you price in upgrade friction and supply-chain review.

How to Pitch It (Stakeholders)

For executives (one paragraph): An open-source add-on that lets admins flip a yes/no switch directly from a list screen, saving a few clicks per action in our internal admin tool. It is functionally appealing but commercially dead — 16 stars, no release since June 2019, and the repository is archived. I do not recommend adopting it as a dependency. I recommend we treat it as a free design reference and spend roughly one to two engineering days replicating the interaction in-house. That gets us the workflow win with no unmaintained code in our stack, and it removes an upgrade blocker the next time we touch the admin framework.

For engineering (the ask): This is a small Nova field that saves in place from the index/detail view. It is archived, era-locked to older Nova/PHP, and has no test suite — supply-chain and upgrade risk outweigh a modest UX gain. Proposal: review the source as a reference implementation, then build our own field with the additions we actually need — per-field authorization, a timestamped audit log of who flipped what, and a confirm step on destructive toggles. Estimate: 1–2 days including tests. Dependency cost: zero.

Framing if challenged on "why not just use it": We could, today, on the current stack. The question is who owns it in twelve months when the framework moves and the maintainer has already walked away. The build cost is measured in days; the migration cost of a baked-in abandoned dependency is measured in sprints.