Nova Column Filter Laravel Package

Product Decisions This Supports

Feature: self-serve ad-hoc filtering vs. curated saved filters. This package makes the case for a generic "column + operator + value" control inside Laravel Nova. The PM decision is whether that is the right product choice, not whether the package is good. Most ops and support users need a small set of consistent, named filters that answer recurring questions — the generic query builder serves the minority power user and shifts cognitive load onto everyone else.

Build vs. buy → port, don't adopt. The functional core is a thin Nova Filter subclass plus a small UI — roughly one engineering day for a Nova-fluent developer. That single fact should drive the decision: use the repo as a reference implementation and a spec for an in-house filter rather than adding it to the dependency tree. The PM decision this package informs is "build or port," almost never "adopt."

Roadmap scope for analytics in admin. If the roadmap includes saved views, compound filters, slicing, or exports, decide early where that lives: Nova filters, a purpose-built saved-report surface, or a BI/lookup tool. Generic filtering inside an admin panel is the thin end of a bad BI tool. This package should not pull Nova into an analytics role.

Persona prioritization. Arbitrary column querying serves the power user who wants any slice. The majority want fast answers to recurring questions. Splitting investment toward curated, index-aware named filters usually yields more value per engineering day than exposing a query builder.

Dependency governance. Adopting a 2019-era, 38-star, zero-dependent, single-maintainer package is a decision to own unmaintained code. If adopted, it needs a named owner, a risk-register entry, and a review trigger at the next Nova major.

Prioritization signal. No release since 2019-02-25 and zero dependents is a "do not invest further" signal. Any modernization effort should compete directly against building a curated filter.

Use cases this supports: internal admin/back-office lookup on low-cardinality, indexed, developer-defined columns such as status, owner, type, or boolean flags; a cheap prototype to show stakeholders what self-serve filtering would look like; and a pattern reference for an in-house app/Nova/Filters implementation.

When to Consider This Package

Consider it when:

• The app runs a Nova 1.x/2.x-era stack — roughly Laravel 5.7–6, PHP 7.2–7.4 — and a generic column filter is needed this sprint.
• You intend to read the source and port the pattern into your own app/Nova/Filters, preserving MIT attribution. Use it as a spec, not a Composer dependency.
• You need a cheap prototype to demonstrate self-serve filtering before committing a roadmap item.
• The exposed columns are plain, indexed, developer-defined table columns with no user-influenced SQL.
• The filter is for an internal admin surface where a broken dropdown has contained blast radius and cannot affect customer-facing traffic.

Look elsewhere when:

• You are on Nova 3, 4, or 5. A 2019 release predates later Nova filter and asset changes. Check Composer constraints before any code review; compatibility failure is the cheapest disqualifier.
• You need maintained code. No release cadence, no dependents, no security feed, no issue triage. Nothing in the ecosystem is pressuring compatibility.
• Performance matters. Generic column querying invites unindexed WHERE clauses, correlated subqueries, and LIKE '%…%' scans on large tables. Prefer curated index-aware filters, generated columns, or a read-replica/BI layer.
• The question repeats. If users ask the same thing weekly, ship a saved filter or report. A query builder produces inconsistent answers across the org.
• Security posture is unclear. Any filter that accepts a column name or raw expression from user input is an injection and data-exposure surface. Hard stop without a developer-defined allowlist and explicit tests that global scopes, soft deletes, and tenant boundaries still apply.
• You cannot own a fork. MIT makes licensing easy; accountability is the issue. If no team will own the code through the next Nova upgrade, do not adopt it.

Cheap validation: half a day to one day — build one Nova Filter with a column allowlist, operator select, value input, and apply() that constrains the query. If the in-house version lands in under a day, the package adds dependency risk without enough leverage.

How to Pitch It (Stakeholders)

To executives: "This is a small, free MIT add-on that would let staff filter admin records by column without filing engineering tickets. It is not a strategic dependency: it has not shipped since February 2019, has 38 stars and zero dependents, and nothing in the ecosystem relies on it. Recommendation: do not adopt the package. Spend about one engineering day reimplementing the same filter in-house so we own the code, stay current with Nova, and control what queries users can run against production data. The strategic question worth answering is whether staff need arbitrary querying at all, or a handful of curated filters that answer their recurring questions consistently."

To engineering: "Single-purpose Laravel Nova column-query filter. Last release 2019-02-25, 38 stars, 0 dependents, single maintainer, no transitive dependencies. The value is the pattern, not the package: a Filter subclass with a column dropdown, operator, and value that applies constraints in apply(). Plan is to port roughly 150 lines into app/Nova/Filters rather than add it to the dependency tree. If someone insists on the package, run a one-day compatibility spike on the exact production Nova/Laravel/PHP versions first, confirm whether it ships a compiled JS asset requiring nova:publish or equivalent, and verify that generated predicates respect global scopes, soft deletes, and multi-tenant constraints. Treat it as first-party code with a named owner and a review trigger at the next Nova major. Failure mode is contained to an admin filter, but silent non-rendering is the likely failure and must be tested, not assumed."

One-line framing for the roadmap doc: "Buy the concept, build the filter."