Group Checkbox Laravel Package

Product Decisions This Supports

• Feature scoping for admin tooling: Determines whether a "group of checkboxes" control (one form field storing a set of selected keys) can be delivered in a Nova resource form without writing a custom Vue field component. Useful signal for estimating admin-panel work in sprints.
• Build vs. buy vs. use-native: The primary decision this package informs. Nova 4 already ships a first-party BooleanGroup field that renders a group of checkboxes and persists JSON. This package is only justified if it adds something the native field lacks (label layout/columns, per-option help text, conditional visibility, custom storage format). That comparison is the actual product decision.
• Roadmap for internal ops surfaces: Relevant to any roadmap item involving per-tenant or per-user toggle sets — notification channel preferences, feature flags, permission/entitlement toggles, weekday or shift availability, fixed-category tagging, multi-channel delivery selection.
• Deployment/risk decisions: With 0 stars and 0 dependents, adoption is a dependency risk decision, not just a UX decision. Supports the call on whether to vendor/fork, pin a commit, or absorb the ~1 field into your own codebase.
• Data modeling decisions: Clarifies whether the attribute is a simple JSON/array column (fits this field) versus a real many-to-many relationship (does not — use Nova's relationship fields instead).

When to Consider This Package

Consider it when:

• You are on Laravel Nova 4 specifically, and the resource form needs a compact, fixed set of boolean options in a single field.
• The option set is small, static, and developer-defined (5–15 keys), not user-managed or searchable.
• You have compared it against Nova's native BooleanGroup and found a concrete capability gap you need.
• You are willing to fork and pin it — treat it as source code you adopt, not a maintained dependency.
• Timeline favors "drop in a field" over "write and test a custom Nova field."

Look elsewhere when:

• You are not on Nova 4, or you plan to upgrade to Nova 5 — there is no evidence of an upgrade path, tests, or CI.
• You need searchable/filterable selection, large or dynamic option sets, or option ordering — use a multiselect or relationship field instead.
• The semantics are genuinely relational (options are entities, need pivots, per-option metadata) — model it as BelongsToMany and use Nova's native relationship fields.
• Your org requires maintained dependencies with a support path, security disclosure process, or multiple maintainers. Single-author, zero-adoption packages rarely clear that bar.
• Native BooleanGroup covers the requirement — which, for most teams, it does. In that case the correct decision is to not adopt and spend the effort on the actual product work.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose UI field for our Nova admin panel that renders a set of checkboxes as one form control. It is cheap to try and cheap to abandon, but it is not a strategic dependency — it overlaps with a feature Nova already provides, and it has no adoption, no visible test coverage, and a single maintainer. Recommendation: treat it as a timeboxed spike or a vendored snippet, not a procurement or platform decision. Worst case is a few hours of engineering, not a migration.

To engineering: Evaluate against the built-in BooleanGroup field first; only proceed if it demonstrably closes a gap (layout, labeling, storage shape, conditional rendering). If we adopt it, fork it into our repo, pin the version, add a feature test covering the JSON round-trip, and confirm behavior on our Nova version. Do not introduce it as a transitive dependency or assume it survives a Nova major upgrade. If the gap is minor, copying ~50 lines of field logic into app/Nova/Fields is likely lower total cost than an external dependency.