Nova Input Filter Laravel Package

Product Decisions This Supports

• Scoping an admin/back-office feature: Decides whether to add free-text typed lookup to Laravel Nova resource lists (customers, orders, users, tickets) instead of forcing ops/support staff to lean on fixed dropdowns or global search. It's a small, contained feature addition — not a platform commitment.
• Build vs. buy for internal tooling: Choose "integrate" when the requirement is a simple typed-value filter on one or a few columns. Choose "build" when the workflow requires compound operators (AND/OR groups), saved filter sets, role-based filter permissions, audit trails, or a multi-field query builder — none of which this package offers.
• Roadmap prioritization / small-wins triage: It enables a low-effort internal productivity initiative (faster record lookup for support and ops) without pulling engineering into custom admin UI work. Frame it as a "small win" candidate competing against other internal-tooling asks, not a strategic investment.
• MVP/pilot gating: Commit to it on one or two high-value Nova resources first, then measure real usage — filter adoption, time-to-find, fewer manual lookup requests — before expanding. Expansion is contingent on pilot evidence, not assumed.
• Platform commitment check: This only carries value if the team has already standardized on Laravel Nova. If Nova adoption is uncertain or under review, this package should not enter the decision at all.
• Risk acceptance: MIT-licensed and released as recently as 2025-01-17, but with weak adoption signals (24 stars, 0 dependents, single-maintainer). Treat it as an accelerator and replaceable tooling rather than a dependency the product leans on — the apply() override pattern means an in-house replacement is roughly a day of work.
• Scope containment: Because the package is stateless configuration and holds no data, the decision is reversible at the config/PR level. That makes it a safe thing to approve in a scoped, timeboxed form.

When to Consider This Package

• Strong fit: The product already runs Laravel Nova, an internal admin resource needs a free-text filter (email, name, reference ID, ticket number), and the team wants to avoid writing a custom Nova filter. All query logic lives in your apply() override, so the learning curve is hours, not days.
• Good use cases: Internal ops/support workflows; replacing a dropdown that fits free-text lookup poorly; replacing a manual global-search workaround on a specific resource; multi-column OR lookups where one typed term searches a handful of fields.
• Reasonable when: The team can pin the exact version, verify Composer constraints against production Nova/Laravel/PHP, run CI against the production Nova version, and accept the documented option to fork or replace it later. The simplicity of the override caps the downside.
• Look elsewhere when: You need complex query building, saved views, advanced operators, role-based filter permissions, audit logging, or high-volume search performance on large tables. A typed input filter can generate LIKE '%term%' full scans; if indexing or scale matters, a purpose-built search layer is the right tool.
• Avoid for: Customer-facing search, public APIs, or any workflow where filter behavior has security or compliance implications without your own validation and authorization review.
• Caution flags: No vendor support, no meaningful community adoption, no long-term maintenance guarantee, and a namespace change from OptimistDigital to Outl1ne that can complicate older tags. If dependency risk outweighs a day of custom work — or the requirement is narrow and stable — build the filter in-house instead.

How to Pitch It (Stakeholders)

Executive summary: A small, MIT-licensed Laravel Nova add-on that lets internal admin users filter records by typing a value instead of picking from a fixed dropdown. It's a low-cost lever for speeding up back-office lookup and avoiding custom admin development. The trade-off is dependency risk — adoption is low and support is community-only — so it should be piloted on non-critical admin screens, pinned to a known version, and treated as replaceable tooling rather than a core platform bet.

For engineering: Integrate behind a short timebox (a few hours to install, register, and validate one filter). Require an empty-value guard on every filter, deliberate casting for numeric/ID lookups, and a hard rule against interpolating user input into whereRaw. Confirm Nova/Laravel/PHP compatibility and whether frontend assets ship precompiled or need a Node build; check which namespace and service provider apply to the installed tag. Add regression tests around target resources, verify that resource policies still govern which rows the filter can surface, and document the fork-or-replace fallback before widening rollout.

For product/ops: Success metrics are filter usage, reduced time-to-find records, and fewer manual lookup requests. Start with one or two high-value, low-risk resources where users already complain about lookup friction; expand only if the pilot shows clear workflow improvement. Each registered filter should have a documented rollback — revert the version pin, disable it in the resource's filters(), or swap to a built-in or in-house filter — so removal is a routine config change rather than an incident.