Nova Global Filter Laravel Package

Product Decisions This Supports

• Whether cross-surface filter parity is a baseline requirement for internal dashboards. Nova filters already scope resource index tables; this package extends the same filter to metrics and custom cards. The product question it forces is explicit: if a dashboard displays a tenant, date-range, or status filter, must every number on the page respect it? If yes, a misaligned KPI is a correctness bug, not cosmetic polish. If no, this is deferred scope. Decide once, write it into your dashboard definition-of-done, and stop re-litigating it per card.
• Build vs. buy vs. copy for internal admin tooling. With 39 stars, zero dependents, and a repo that has been archived after a brief Nova 4 revival, the defensible PM call is vendor the pattern and own the code — not adopt the package as a long-lived dependency. That is a resourcing decision (a few engineering days plus a named owner in CODEOWNERS), not a procurement one. Record it in the decision log so a future maintainer doesn't reopen the question.
• Roadmap sequencing between internal analytics trust and customer-facing work. This is a narrow, bounded enhancement to ops, support, and finance dashboards inside Nova. It touches nothing customer-facing and carries no revenue risk. Frame it as a small, low-risk item that buys credibility in internal reporting — not as a platform investment competing with customer work for the same capacity.
• Validating demand before committing. Concrete use cases to test against: ops dashboards where one date-range filter must drive every KPI card; support consoles where a tenant filter scopes both lists and trend metrics; finance views where users expect one filter bar to govern the whole page. If users are not asking for this, and are not visibly confused by mismatched numbers today, it is speculative and should stay on the shelf.
• Standardization across teams building Nova dashboards. If more than one team ships Nova dashboards, an agreed pattern for filter propagation prevents each team from quietly inventing a different answer to "what does this filter apply to?" That inconsistency is exactly what erodes trust in internal numbers, and it is cheapest to prevent before the second dashboard exists.
• Nova upgrade scoping. v1.3.0 added Nova 4 support, which converts "unify filter state" from a from-scratch build into a scoped workstream. The upgrade plan should either include it or explicitly defer it with a named owner — leaving it unnamed is the only wrong answer.
• Setting the trust bar for internal reporting. The dominant failure mode is silent: an unfiltered metric renders a plausible number, not an error. That has a product consequence — any dashboard surfaced to decision-makers needs a verification step, and this package is a good reason to formalize one (a propagation test in CI, not a screenshot review).
• Defining what "done" means for a card. Adoption forces a written contract per card: which filters it consumes, what it does when none are applied, and how timezone and date-boundary semantics are handled. That contract is valuable independent of whether you take the code.

When to Consider This Package

Consider it when:

• You run Laravel Nova 3 or Nova 4 and users apply a filter to a resource index that metrics or custom cards visibly ignore. That gap is the entire value proposition — if it doesn't exist for you, there is nothing here to buy.
• Your Nova version falls inside the package's composer constraints. Verify against your pinned Nova minor before committing; an archived upstream will not chase future breaking changes, and "Nova 4 support" does not enumerate which minors were tested.
• You have multiple cards needing the same filter context, so the consistency win is real rather than cosmetic. One card with one filter does not justify an integration — a direct request-parameter read in that card is cheaper to own.
• Your team is willing to fork or vendor MIT-licensed code and own it, tests included. Treat upstream as a reference implementation, not a warranty.
• You want a cheap, timeboxed proof of concept of cross-card filter state before deciding whether to build a native equivalent.

Look elsewhere when:

• You are on Nova 5+ or any version this package predates. A "Nova 4 support" release landing in 2023 on a since-archived repo is a catch-up signal, not a maintenance cadence.
• Your organization requires actively maintained dependencies with security patching and predictable releases. Zero dependents means no production population has validated lenses, relationship filters, multi-filter composition, soft-delete scoping, or policy-scoped resources — you would be the edge-case discovery team.
• You are not on Nova. The value is entirely Nova-specific; build the equivalent in-house for any other admin stack.
• Your filter needs are simple or single-card. A small internal helper is cheaper to own than an integration to babysit.
• A native Nova mechanism already exposes filters to cards. Then the build-vs-adopt question collapses and this becomes a design reference only — go native.
• You need capabilities it does not offer (custom serialization, per-card filter subsets, cross-page persistence). Extension points are thin by design and there is no maintainer to accept a PR; fork rather than fight it.
• Authorization is the actual requirement. Global filters scope what a user sees, not what they may access. If the driver is "tenant isolation," the work belongs in the query/policy layer, not the filter bar.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost improvement to internal admin dashboards: one filter bar that reliably scopes every metric and card on the page, which reduces "why don't these numbers match?" confusion for ops, support, and finance. It is contained entirely inside the admin panel — the worst case is a misleading internal number, never a customer-facing incident. The 2023 release that added Nova 4 support means the pattern is already proven; the recommended path is to copy roughly a hundred lines of MIT-licensed code into our own codebase and own it, rather than take on an unmaintained dependency. Ask: two to three engineering days, no new vendor, and a clear improvement in trust for the dashboards people use to make decisions. Say no if no one is currently confused by mismatched numbers — this buys consistency, not new capability.

For engineering: Upstream is a trait, a service-provider registration, and a small inline Vue component that reuses Nova's existing filter UI — archived, 39 stars, zero dependents, last touched for Nova 4. Do not composer require it as a dependency. Read the three source files, lift the pattern into app/Nova/Concerns with MIT attribution and a CODEOWNERS entry, and wire the canonical filter set into NovaServiceProvider so each resource's filters() resolves from one source instead of duplicating classes. Two guardrails before any rollout: (1) a feature test asserting a dashboard metric actually respects the broadcast filter, plus its inverse — a card that ignores the filter, which must fail CI; (2) a filter-state location check — if state lives in session or component state rather than the query string, shared links silently show different numbers to different people, so don't promise bookmarkable dashboards until that's confirmed. Budget explicit time for composition edge cases (global filter + local relationship filter + lens + soft deletes) and for the nova:clear-cache stale-asset trap. Add two steps to the Nova upgrade runbook: re-run the propagation test, re-read the upstream composer.json constraint. If the ask is a single card, skip all of this — one request-parameter read is cheaper to own.