Nova Filterable Cards Laravel Package

Product Decisions This Supports

• Dashboard roadmap: per-card filters vs. one global filter. Every internal analytics dashboard hits this fork. This package is a working answer — each metric card carries its own date range, plan, channel, or tenant filter — and is worth reviewing before funding a component library or a bespoke build.
• Build vs. buy vs. vendor sizing. It is a small, readable reference implementation: a PHP card class that decodes Nova's filters query parameter and replays each filter's apply() against the card's metric query, plus a Vue control in the card header. That is enough to scope an in-house equivalent at roughly one to three sprints — without paying for discovery or UX design.
• Feature definition for an existing Nova admin panel. If the back office already runs Nova, this tells you whether "filterable KPI cards" is a cheap increment or a funded capability gap.
• Self-serve ops outcome. Filterable cards let ops, finance, and CS slice revenue, signups, and churn without filing ad-hoc SQL requests — a measurable PM result (deflected requests per month), not a purely technical choice.
• Risk-register input. Archived, zero dependents, 2018-era Vue 2 frontend, single maintainer. Adopting it as a dependency puts an unmaintained component into the admin surface and complicates any future Nova major upgrade.

When to Consider This Package

Consider it when:

• You are pinned to Laravel Nova 1.x/2.x (or legacy Laravel 5.6/5.7, PHP 7.1) and need per-card filters this quarter.
• The dashboard is internal-facing only, so a stale UI dependency carries no customer-facing blast radius.
• Your team can fork and own it — MIT, small, self-contained, readable in under a day. Vendoring is realistic.
• You need a prototype or design reference to validate that filterable cards actually change user or ops behavior before funding a real build.

Look elsewhere when:

• You are on Nova 3+/4+/5. Native cards can refresh when dashboard filters change (refreshWhenFiltersChange()), which largely duplicates this package's reason to exist. Verify this first — if confirmed, the package is obsolete.
• You need cross-card filtering, saved views, drill-downs, or export — that is BI territory (Metabase, Looker, Redash).
• You require security patching, PHP 8+ support, Vue 3, or vendor SLAs. Last release August 2018; repository archived; 58 stars, zero dependents, effectively no field testing.
• You have no existing Nova investment — Nova is a paid license, so this drags in a second purchase for a filtering convenience.
• Anyone in the estate references the GitHub URL as a vcs Composer repository — treat that as an immediate supply-chain item, since deletion breaks builds.

How to Pitch It (Stakeholders)

For executives: This is a small MIT-licensed add-on that lets each metric card on a Laravel admin dashboard carry its own filter — so a "Monthly Revenue" card can be scoped to a plan or region without rebuilding the whole page. The strategic value is not the code; it is the validated pattern. It confirms that filterable KPI cards are a low-cost, high-leverage lever for cutting ad-hoc data requests from ops and finance. The package itself is archived, unmaintained since 2018, has no downstream users, and targets a Nova version we are unlikely to be on — so I am not recommending it as a dependency. I am recommending we treat it as a reference design and fund a small, owned implementation, or confirm our current Nova version already covers the need, in which case we close the gap for near-zero cost.

For engineering: It is a thin Nova card abstraction plus a Vue 2 filter component: a PHP base class that reads the dashboard's filters parameter, decodes it, and applies each filter to the card's metric query, and a frontend control injected into the card header. There is no service-provider asset registration — you register your own cards as usual. The integration path is not composer require; 2018-era constraints (php ^7.1, laravel/framework 5.6|5.7, laravel/nova ^1.0) fail resolution on modern stacks. The right move is a one-to-two-day clean-room reimplementation against current Nova scaffolding, using the source as a behavioral reference. The real work is not the widget — it is defining the filter contract: which dimensions, how scoped by policy and tenant, how composed with Nova's native filters, and how date-range boundaries and timezones are handled. Note the scaling surface too: each card issues its own aggregate query and re-queries on every filter change, so confirm indexes on filtered timestamp columns and consider caching before rolling this out over large tables. If we do vendor instead of reimplement, mirror the code into our own VCS and pin supported Nova/PHP versions in the fork's README — do not depend on the archived upstream.