Nova Global Filter Laravel Package

Product Decisions This Supports

• Feature decision: make dashboards trustworthy. Today, Nova metric cards on Dashboards and resource Detail views typically show unfiltered, global numbers while the Index list shows a filtered subset. That mismatch is a recurring source of "the dashboard says 1,240 but the list says 318" support tickets. This package lets existing Nova filters apply to cards, so the same filter definition drives lists and metrics — closing a credibility gap in internal reporting.
• Roadmap input: filter once, apply everywhere. Because it reuses filters the team has already built for Index views, segmentation (region, team, owner, status, date range) becomes a shared primitive rather than something re-implemented per card. Lowers the cost of adding new dashboard views and prevents drift between "reports" and "lists."
• Build vs. buy: buy (adopt) over build, with a vendor-and-pin caveat. The alternative is custom card development — bespoke query plumbing per card, plus duplicated filter UI. That's typically 1–2 engineering days for a first pass and ongoing cost every time a card changes. This is a small, MIT-licensed, single-purpose package: cheaper to review and vendor than to reimplement.
• Use cases to prioritize: operational dashboards segmented by region/team/status; support and queue health views scoped by assignee; sales pipeline cards filtered by owner or stage; Detail-view cards that scope to the current record's attributes.
• Explicitly not a decision it supports: customer-facing or embedded analytics, multi-tenant isolation, or permission-aware metric scoping. Those need policy-driven query layers, not UI filters.

When to Consider This Package

Adopt when:

• You are already running Laravel Nova (paid license) — a hard prerequisite; without Nova this package has zero surface area.
• You maintain custom cards or metrics that need the same segmentation your Nova filters already express (date ranges, ownership, status, team).
• You want filtered Dashboards and Detail-view cards without asking users to learn a second filtering UI.
• You can accept the maturity risk: 1 GitHub star, 0 dependents, single maintainer. Treat it as a vendored snippet, not a supply-chain dependency — read the source (small enough to review in under an hour), fork it into your codebase, and pin it.
• The value is worth a timeboxed spike rather than a formal procurement.

Look elsewhere when:

• You're not on Nova, or you're on a Nova version where filterable cards / filterable metric traits are natively supported — verify the built-in capability for your exact version first, since Nova's own feature set has evolved and can make this redundant.
• You need SLA-backed support, active maintenance guarantees, or a security-reviewed vendor.
• Your real requirement is query-level scoping (row-level permissions, multi-tenancy, global Eloquent scopes) — that belongs in policies and scopes, not dashboard filters.
• Your cards use bespoke aggregation logic that isn't filter-aware by design; the package won't retrofit that.
• The audience is external customers; Nova is an internal admin surface and the wrong foundation for embedded reporting.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, MIT-licensed utility that makes the numbers on our Nova dashboards match the numbers in our filtered list views. The practical outcome is fewer "these figures don't add up" escalations and restored trust in internal reporting, at essentially no licensing cost and no new UI for users to learn. The risk is low and contained: the package is tiny and we will copy the source into our own codebase rather than depend on it, so maintenance is ours and the exit path is trivial. Recommendation: approve a short timeboxed spike on one dashboard before committing.

To engineering (summary): Single-purpose package extending Nova to apply existing Filter classes to cards in Dashboards, Index, and Detail views. Reuses your own filters, so no new filter definitions. MIT, small surface, single maintainer with negligible adoption — do not add as a Composer dependency; vendor the code, review the query path, and pin the Nova version compatibility. Fallback if it doesn't hold up: 1–2 dev days to implement equivalent filterable-card behaviour in-house. Success criteria for the spike: a filtered dashboard card that returns results matching the equivalent filtered Index query, verified against two or three real filter combinations.