Nova Column Filter Laravel Package

Technical Evaluation

Architecture fit. For a TPM the relevant fact is that this is a leaf dependency with near-zero architectural footprint. It hooks only into Laravel Nova's filter extension point — registered in a resource's filters() method, rendering in the index filter panel, appending a where constraint to the index query. No service providers, migrations, published assets, queue or cache surface. That means the adoption is reversible and low-blast-radius: the program risk is not "does this destabilize the platform," it is "is the maintenance ownership worth it." The decisive architectural gate is Nova itself — a commercial per-site licensed product. If the org is not on Nova, the package is dead on arrival and the assessment ends there.

Integration feasibility. Trivial to wire (composer require, one array entry, a column reference), so the engineering effort is not the constraint — governance is. The TPM's job is to frame this as a bounded, timeboxed spike (one engineer, 1–2 days) that produces a go/no-go, not an open-ended platform bet. The two gates that determine go/no-go:

• Nova major-version compatibility — Nova's Filter contract and stubs shifted across v3/v4/v5; a 9-star/0-dependent package is unlikely to have tracked those. This is the first blocking check.
• Query safety — column name and operator must be developer-supplied, never request-derived. Otherwise it is an injection and column-enumeration surface in a PII-touching admin panel.

Technical risk. As a program-level risk register:

• Supply chain / abandonment (high likelihood, medium impact). Nine stars, zero dependents, single maintainer, no disclosure process. Every Nova major upgrade is ours to absorb. Mitigation is cheap and should be the default end state: vendor the class into app/Nova/Filters/ under our namespace and drop the Composer dependency.
• Query safety (low likelihood if reviewed, high impact). Latent SQL-injection/column-enumeration if inputs are request-derived. Blocking source-review item; mandate a column allowlist.
• Authorization & scoping (medium likelihood, high impact). The appended where must compose with Nova's indexQuery and authorization pipeline so a user cannot filter their way into another tenant's data. Must be verified explicitly, not assumed.
• Semantic drift (medium, medium). Raw column filtering exposes DB semantics (nullable, enums, JSON paths, soft deletes) rather than business dimensions — often not what stakeholders asked for.
• Silent no-op (the worst failure mode). After a Nova upgrade the filter may render but stop constraining the query; admins then act on unfiltered data. Requires a smoke test as a standing guardrail.

Key questions.

1. Which Nova major, Laravel, and PHP versions do we run, and does the package's composer.json allow them? (Blocking.)
2. Does it validate the column against schema or an allowlist, or accept arbitrary strings? (Blocking.)
3. Does it respect indexQuery and Nova's authorization pipeline? (Blocking.)
4. Does it support the operators we need (=, like, in, between) or only a single select?
5. Does filter state serialize correctly into Nova's URL and per-user persisted state?
6. Is the license permissive enough to vendor the class?
7. Is the real requirement "filter by any column" or "filter by a curated set of business dimensions" — in which case Nova's built-in SelectFilter/BooleanFilter already cover it and this dependency buys nothing?

Integration Approach

Stack fit. Laravel + Nova + Composer, nothing exotic. The deploy artifact is a lockfile change; rollback is a revert. No migrations, no external services, no workers. Blast radius confined to Nova index screens on internal admin resources. For a TPM this is the desirable shape: a change one team can ship and reverse without a cross-team release train.

Where it fits. Back-office index screens where operators need ad-hoc narrowing — status, tenant, region, created-at buckets, partial email/phone lookups — on the long tail of resources that do not each justify a bespoke filter class. It is a convenience shim, not a platform primitive. Explicitly out of scope and to be stated as such to stakeholders: relationship filters, multi-select across related models, authorization-sensitive views, and full-text relevance (use Nova search/Scout).

Migration path (milestones).

1. Proof-of-concept on a single least-critical internal Nova resource in staging — timebox: half a day including a source read-through.
2. Confirm Nova major compatibility and pin the exact version — no caret range.
3. Preferred end state given 9 stars/0 dependents: vendor the ~150-line class into app/Nova/Filters/, verify the license permits it, drop the Composer dependency, own it outright. One readable file is cheaper to own than to track.
4. Codify an internal convention: when to use this filter vs. a bespoke filter vs. built-in SelectFilter, plus a mandatory indexed-column rule and a review-checklist item for column allowlisting.

Compatibility. Check PHP, illuminate/support, and laravel/nova constraints together. Because Nova resolves from nova.laravel.com, CI needs Nova credentials — verify the package's constraints don't create a resolution conflict that blocks deploys (a failed composer update in a pipeline is an outage for admin tooling). Confirm the target Nova major before investing beyond the source read-through.

Sequencing (with gates).

1. Confirm Nova license and major-version baseline — blocking.
2. Source read-through (~1 hour) and sign-off on injection and scoping posture — blocking.
3. Build one reference filter and document the pattern.
4. Add code-review checklist items (column allowlisting, indexed columns).
5. Expand to other internal admin resources only after steps 1–4 hold.
6. Add a smoke test exercising a text column and a date column against our Nova version, verifying the filter still constrains the query.

Operational Impact

Maintenance. Effectively ours from day one. With zero dependents there is no community to absorb Nova upgrades — budget a few hours per Nova major, or vendor the class and stop treating it as an external dependency. Be explicit with stakeholders that the ongoing ownership cost exceeds the original acquisition cost; it is small but real, and it belongs in the admin-tooling line item, not assumed away. Prefer vendoring over a floating dependency so upgrades are an explicit decision rather than automatic lockfile drift.

Support. No vendor, no SLA, no CVE pathway. Internal owner is the admin-tooling or platform team. Keep it on the admin-tooling on-call surface, not the core product surface. Establish a policy call — once — on third-party code in admin paths that touch PII: pinning, vendoring, and auditing rules. That decision outlives this package and is the durable output of this evaluation.

Scaling. Scales in the direction that matters: adding resources and columns is cheap configuration, which is the whole value proposition. It does not scale into complex filtering (relationships, cross-model, authorization-aware scoping) — pushing it there generates the exact fight-with-the-framework work it was meant to eliminate. Enforce the boundary: indexed columns only, allowlisted columns only.

Failure modes to plan for.

• Silent no-op after a Nova upgrade — filter renders but no longer constrains results; admins decide on unfiltered data. Primary guardrail: smoke test.
• Injection / column enumeration — mitigated by developer-supplied column+operator and an allowlist.
• Cross-tenant leakage — mitigated by verifying indexQuery/authorization composition before rollout.
• Semantic mismatch — admins filter by raw DB semantics not business dimensions; mitigated by scope guidance steering curated needs to SelectFilter/BooleanFilter.
• Dependency resolution break in CI — mitigated by pinning/vendoring.

Ramp-up. Low and bounded: one reference filter plus a documented pattern, a code-review checklist, and a short convention note cover the team. Plan for the TPM-facing communication: executives get the one-paragraph "cheap accelerator, timeboxed spike, downside bounded to 1–2 engineer-days, upside measurable in reduced admin-tooling tickets"; engineering gets the "vendor, pin, test, audit injection and scoping before ship" brief. If the source audit turns up anything uncomfortable, the fallback — write the equivalent ourselves in 3–5 days — is already budgeted and low-cost, which is what lets this stay a cheap experiment rather than a platform bet.