- What does marshmallow/nova-global-filter do?
- It is a Laravel Nova package that lets you broadcast filters already defined on a Nova resource to metric cards and custom cards. Nova filters normally only apply to the resource index request, so metrics calculated in their own AJAX requests show unfiltered numbers. This package bridges that gap so a Value, Trend or Partition metric can respect the same filter criteria as the resource list it mirrors. It only makes sense inside a Nova installation that has dashboards paired semantically with a filtered resource.
- How do I install marshmallow/nova-global-filter?
- Install it with Composer using composer require marshmallow/nova-global-filter. The package is MIT licensed and relies on Laravel package auto-discovery, so no manual service provider registration should be needed. No migrations or database changes are expected, though there may be a publishable config file worth reviewing. Budget a short spike rather than assuming install-and-go, since the integration point touches Nova internals.
- Which Laravel and Nova versions are supported?
- The package targets Laravel 10, 11 and 12 with Nova 4 or 5 on PHP 8.1 and above. Confirm the supported matrix against the composer.json constraints rather than relying on prose, and check whether the ranges are actually asserted in tests. Nova is closed source, so a minor Nova release can change internals without a deprecation path. Pin your Nova version and re-run a smoke test after every upgrade.
- How does filter state get from a resource request to a card request?
- Cards compute during their own separate AJAX request, after the resource index request is finished, so state must be persisted somewhere. The plausible transports are a query parameter, the session, the cache, or values published into card meta, each with different correctness and isolation trade-offs. Read the source to see exactly which one is used and whether it is keyed per user and per resource. That detail determines whether the package is safe for you.
- Do filters that return closures or read the request user work correctly?
- Nova filters can return closures from apply() or depend on the current request and authenticated user, which does not serialize cleanly. Any transport that assumes scalar values will silently mis-apply those filters instead of throwing an error. Treat closure-returning filters and user-scoped filters as the first thing to verify in your spike. If your filters encode authorization scope such as team-only visibility, validate this before shipping.
- Can this package leak data between users or tenants?
- The risk is real because filter state now outlives the request that produced it. If state is stored globally in the cache or session without being keyed per user, per resource and per tenant, one user's filter could shape another user's metrics. Nova filters are frequently used to encode authorization scope, so a bug here is a data exposure incident rather than a cosmetic defect. Test with two concurrent users and with tenant switching before trusting it in production.
- What happens when a user changes filters or navigates away?
- There needs to be a clear invalidation story for filter state: what happens on change, on navigation away, and on tenant switch. Check whether stale state persists and gets applied to a card the user is no longer filtering, which would produce quietly wrong totals. Also consider whether a card can render before any filter has ever been broadcast, and what the fallback is in that case.
- Does it work with dashboard-level filters or multiple resources on one dashboard?
- The package is described as broadcasting resource-index filters, not Nova dashboard-level filters, so do not assume dashboard filters propagate. A related question is which resource's filter state wins when several filtered resources feed the same dashboard. If your dashboard mixes metrics from different resources, confirm the keying strategy in the source before relying on it. This is one of the highest-value questions to resolve in a one to three day spike.
- How do I test that a metric is actually showing filtered numbers?
- The worst failure mode is not an exception but a card quietly showing unfiltered totals that someone quotes in a meeting. Write a test that applies a filter, loads the card endpoint, and asserts the aggregate changes to the expected value. Add a negative case where no filter is applied and a case where the filter excludes everything. Also assert isolation by loading the card as a second user with different scoping.
- Is the package maintained, and should I depend on it or fork it?
- Signals are thin: a single maintainer, no visible CI or test story, zero dependents and no public reference implementations. Treat this as source you adopt rather than a dependency you consume, because there is no upstream community to absorb breakage on your behalf. Forking into an internal namespace with your own tests and README converts an unmaintained external package into something you control. If you adopt at all, that is the recommended path, and it also removes the urgency of any Nova breaking change.