Nova Global Filter Laravel Package

Technical Evaluation

Architecture fit. The package is a thin, targeted extension to Laravel Nova's existing filter system: a trait that resolves filters per resource, a service-provider registration that broadcasts them, and a small inline Vue component that reuses Nova's filter UI. It adds no new datastore, no new service, and no new runtime dependency beyond Nova itself. That is the right shape for the problem — the value proposition is narrow (a filter applied on a resource index should also scope metrics and custom cards on the same page), and the implementation surface appears to match it. The package is Nova-specific by definition; if the admin stack is not Nova 3/4, there is nothing here to evaluate.

Integration feasibility. Feasible on Nova 4, with conditions. The last release is v1.3.0 (2023-03-08) and its entire changelog entry is "Nova 4 support" — which does not state which Nova 4 minors were tested. Integration requires pinning the exact version (nemrutco/nova-global-filter:1.3.0), reading vendor/.../composer.json to confirm the laravel/nova constraint actually covers the pinned minor, and reading the three source files before wiring anything. The design intent — define filters once in NovaServiceProvider, have resources resolve filters() from that source — is a sound pattern regardless of whether we adopt the package or copy it.

Technical risk. The dominant risk is not a crash; it is a plausible-looking wrong number. A metric or card that ignores the broadcast filter renders a normal, unscoped value on exactly the surface where someone makes a decision — no 500, no log line. Secondary risks: the repo is archived upstream (no future Nova compatibility), it has 39 stars and zero dependents, meaning lenses, relationship filters, multi-filter composition, soft deletes, and policy-scoped resources have no production population behind them. Extension points are thin by design, so custom serialization, per-card filter subsets, or cross-page persistence would require forking. A separate and more serious risk is conceptual: filters are UI convenience, not authorization. A global tenant filter scopes what a user sees, not what they may access; scope enforcement must remain in the query/policy layer, and a clean filter bar must not create the impression otherwise.

Key questions.

• What Nova major and minor are we pinned to? (Nova 5+ → stop; port the pattern.)
• Does the Vue component read filter state from the query string or from session/component state? This decides whether dashboards are bookmarkable and shareable, or silently show different numbers to different people.
• Is cross-surface filter parity a stated requirement for internal dashboards, or speculative scope? The answer determines defect vs. enhancement.
• Are we adopting the package as a dependency, or vendoring the MIT-licensed pattern into app/Nova/Concerns with a named owner in CODEOWNERS? (The docs point firmly at vendoring.)
• Does any native Nova mechanism already expose filters to cards? If so, this collapses to a design reference.
• Which resources in scope carry pre-existing local filters, lenses, or soft-delete scoping — i.e., where will composition questions surface first?

Integration Approach

Stack fit. Laravel + Composer + Nova 3/4, with the inline Vue component compiling into the host app's Nova assets. Zero fit outside Nova. The realistic shape is a small internal enhancement to ops, support, and finance dashboards — contained entirely inside the admin panel, no customer-facing surface, no revenue risk.

Migration path. Two options, and the recommendation is the second:

1. Spike (timeboxed): composer require nemrutco/nova-global-filter:1.3.0, exact pin, on one dashboard only. Purpose is to validate that the pattern works before committing.
2. Adopt-by-vendoring (recommended): copy the trait, provider registration, and Vue component into app/Nova/Concerns (or a private package), strip the upstream namespace, retain MIT attribution, add to CODEOWNERS. This buys the pattern without inheriting an unmaintained dependency, and lets us patch when Nova moves. The package's own docs describe this as the recommended path even on Nova 4.

Compatibility. Nova 4 only as of v1.3.0. On Nova 5+ the package is out of scope — port the pattern instead of installing. Two mechanics to bake into the runbook: after changing provider-level filter registration, run nova:clear-cache and re-cache routes if routes are cached (a stale compiled Vue asset is a common cause of "the filter bar didn't change"); and on every Nova bump, re-read the composer.json constraint and re-run the propagation test.

Sequencing.

1. Confirm Nova version and minor; verify against the package's laravel/nova constraint if a spike is approved.
2. Read the trait, service provider, and Vue component (~10 minutes) to determine whether v1.3.0 touches Nova internals (fragile) or public extension points (portable).
3. Centralize the canonical filter set in NovaServiceProvider; have every in-scope resource's filters() return from it. Do not duplicate filter classes across resources — that defeats the purpose and creates drift.
4. Run the one smoke test that matters: one dashboard, one date-range filter, two metrics, one custom card, one resource table — confirm all four move together on the same request.
5. Add the propagation contract to CI: a feature test asserting the metric is scoped when the filter is applied, plus the inverse test asserting a card that ignores the filter fails the build. That inverse test is the entire safety net.
6. Roll out to additional dashboards (tenant-scoped support console, finance views) only after parity holds.
7. If more than one team ships Nova dashboards, publish the agreed pattern before the second dashboard exists — inconsistency across teams is what erodes trust in internal numbers.

Operational Impact

Maintenance. Upstream is archived; treat it as a reference implementation, not a warranty. There is no maintainer to take a PR, so any custom need is a fork, not a feature request. Vendoring converts an unmaintained dependency into owned code with an owner and a diff history — a few engineering days of resourcing, not a procurement exercise. Every Nova upgrade adds two mandatory runbook steps: re-run the propagation test and re-read the version constraint.

Support. No upstream escalation path. Support load will not look like incidents; it will look like "the numbers are wrong" tickets, which are expensive to triage because the failure is silent. Standardize the debug order so the team does not rediscover it per ticket: dump the raw request payload at the card's endpoint → confirm the filter key is present → confirm the card's query actually reads it → only then inspect the Vue component. Most reports stop at step one; step four is almost never the culprit.

Scaling. The package itself is not a scaling concern — resolution is per-request and cheap. The scaling concern is organizational: multiple teams building Nova dashboards will each invent their own answer to "what does this filter apply to?" unless a pattern is agreed up front. On the data side, watch composition: global filters alongside locally-defined relationship filters, lenses, and soft-delete-scoped resources is where ordering, deduplication, and "which one wins" surface — and where zero dependents means nobody has stress-tested it for us.

Failure modes.

• Unfiltered metric (dominant): renders a plausible number, no error, no warning. Assume any new card is unfiltered until a test proves otherwise.
• Non-shareable state: if filter state lives in session or component state rather than the query string, a shared link silently shows different numbers to different people.
• Date boundary and timezone drift: "last 30 days" computed inside a card versus inside the resource query can differ by a day and by timezone. Assert against the same fixture data in both.
• Duplicate filter bars: a resource with a pre-existing local filter plus the inherited global set can render two controls with the same label — two numbers on one dashboard the user cannot adjudicate.
• Authorization misconception: a user who strips a query parameter must not gain data. Scope enforcement stays in the query/policy layer.
• Stale asset build: after provider-level registration changes, clear Nova cache and re-cache routes.

Ramp-up. Low. The surface is three files; a competent Laravel engineer can read it in an hour and wire the first dashboard in a day. The real ramp is procedural, not technical: teams must learn to test the propagation contract rather than eyeball a screenshot, and must accept that edge-case discovery is on us. Budget explicit time for a parity check on every dashboard — the table and the KPI cards must agree on the same request, not merely look plausible.