Nova Column Filter Laravel Package

Product Decisions This Supports

• Standardize vs. bespoke internal admin filtering. Today, every "can you add a filter for X?" request is a ticket plus roughly an engineer-day of hand-written Nova Filter work. This package reduces that to a configuration line per column. The decision it informs: do our ops-facing Nova screens get column-level filtering by default, or does each request stay a one-off build?
• Build vs. buy (framed honestly). At 9 stars and 0 dependents, this is not a dependency to trust — it is source code to evaluate. The real comparison is ~1–2 engineer-days to vendor and own ~150 lines versus ~3–5 days to write and test equivalent filters across N resources. It only tips the decision when N (long-tail admin resources needing simple filters) is large enough that per-resource filter classes become genuine maintenance drag.
• Feature scoping for recurring support/ops workflows. Each of these is currently a small ticket that a generic column filter collapses into one capability: support looking up a customer by partial email or phone; finance filtering transactions by status and date window; operations triaging records by a boolean or enum column.
• Investment level in internal admin UX. Repeated "add a filter for X" requests signal the admin surface is under-built. This is a cheap, bounded way to test whether broader filterability actually reduces support load before committing to a larger internal-tools investment — an experiment, not a platform bet.
• Risk posture for third-party code in admin paths. Admin panels routinely touch PII. Adopting an unmaintained package forces an explicit, reusable call on pinning, vendoring, and auditing — a policy decision that outlives this package and should be made once, deliberately.
• Where filtering must not substitute for product thinking. Raw column filtering exposes database semantics (nullable flags, enums, JSON paths, soft deletes) rather than business dimensions. If the real requirement is "filter by curated business dimensions," Nova's built-in SelectFilter and BooleanFilter already cover it and this adds nothing.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova — this is Nova-specific with zero value outside it. Nova's commercial per-site license is a hard prerequisite.
• You have many resources where stakeholders repeatedly request simple, column-level filters, and writing a bespoke Filter subclass per column per resource has become repetitive.
• The filtering needs are simple predicates — equals, contains, date ranges, boolean/enum selection — on columns that already exist on the resource's table.
• Your team is comfortable vendoring or forking a small package: copy the filter class into app/Nova/Filters under your namespace, pin it, and own it. Treat upstream as a reference implementation, not a supported dependency.
• You can absorb the operational cost: a few hours per Nova major upgrade, a mandatory indexed-column rule, and a smoke test proving filtering still constrains the query.

Look elsewhere when:

• You are not on Nova, or you're on a Nova major version this package doesn't target. Version compatibility is the first thing to verify — Nova's Filter contract and stubs changed across v3/v4/v5, and a 9-star package is unlikely to have kept pace.
• You need relationship filters, multi-select across related models, or authorization-aware scoping. Those belong in Nova's built-in filter machinery or a filter you control; a generic column filter will fight you on query scoping and access control.
• You need full-text search relevance — use Nova search / Laravel Scout, not a LIKE %...% column filter.
• Maintenance guarantees are a policy requirement. Nine stars, zero dependents, single maintainer, no disclosure process, no issue triage. If policy forbids unmaintained code in admin surfaces, this fails regardless of utility.
• The column set is small and stable — one or two custom filters are cheaper than the vetting, vendoring, and upgrade-testing overhead.
• The requirement is really "filter by a curated set of business dimensions," where built-in SelectFilter/BooleanFilter win on supportability.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost accelerator for our internal admin panel. It turns "add a filter for this column" requests — the kind that currently generate a ticket and an engineer-day each — into configuration instead of custom code, and it directly targets recurring support workflows like looking up a customer by email or filtering transactions by status and date. The catch is community size: nine GitHub stars and no downstream users means we should not treat it as a strategic dependency. My recommendation is a timeboxed spike — one engineer, one to two days — to evaluate it against our Nova version and, if it fits, vendor the code into our repo so we own it outright. Downside is bounded to that spike; upside is a measurable reduction in internal-tooling tickets and a cheap test of whether better admin filtering actually lowers support load.

For engineering: It's a thin Nova filter base class that maps a resource column to an appropriate filter input — small enough to read end-to-end in an afternoon and small enough to fork without regret. Proposal: vendor it under app/Nova/Filters, pin the version in the README, and add one test exercising a text column and a date column against our Nova version. Two things must clear source review before we ship it: the column name and operator must be developer-supplied and never request-derived (otherwise it's an injection and column-enumeration surface), and the appended where clause must compose correctly with Nova's indexQuery and authorization pipeline so a user can't filter their way into another tenant's data. Do not add it to composer.json as a floating dependency. Do not use it for authorization-sensitive or customer-facing screens — those get custom filters. Enforce an internal convention: indexed columns only, plus a review-checklist item for column allowlisting. The worst failure mode to guard against is a silent no-op after a Nova upgrade, where the filter renders but no longer constrains the query and admins make decisions on unfiltered data — hence the smoke test. If the audit turns up anything uncomfortable, we drop it and write the equivalent ourselves; the fallback cost is low and already budgeted.