feat(web): chip-bar device filter UI (#968 PR 2)

[bdunncompany]

PR 2 of 3 for the chip-bar device filter (#968). The web UI, on top of #968 PR 1's completed filterEngine.

⚠️ Stacked on #1012 (PR 1). This branch includes #1012's commits, so until #1012 merges the diff shows the API work too. Once #1012 lands I'll rebase onto main and the diff resolves to web-only, then mark this ready. Opening as draft now for visibility.

What it does

A NinjaOne-style chip bar on /devices. It builds a FilterConditionGroup and feeds it through the existing DeviceList serverFilter → POST /filters/preview → matchingIds client-intersection path that's already on main — no new device-list query, no change to the keyset cursor.

• FilterChipBar — chips = conditions in the top-level AND group; click to edit (operator + value), X to remove, "+ Add filter" field picker (FilterAddDropdown).
• FilterValueEditor — per-type value editing incl. software multi-select (text entry; the name-autocomplete picker needs a distinct-software endpoint, follow-up).
• FilterSentenceBuilder — advanced/nested-group mode when the filter isn't chip-renderable (OR / nested).
• FilterPreviewFooter — live "N devices match" via /filters/preview.
• QuickAddChips — one-click toggles (Online, Offline, Servers, Needs patches, Critical, Reboot needed, Not seen 7d, Low disk, Untagged). All of these now evaluate server-side thanks to PR 1.
• filterUrl.ts — shareable #filtersV2=<base64> hash + the filtersV2 flag: default ON, opt out via ?filtersV2=0 or localStorage['breeze.filtersV2']='off'. Per your Proposal: chip-bar filter UI for /devices — working prototype in production #968 note, the flag + legacy DeviceFilterBar stay one release window, then get removed.
• DevicesPage renders the chip bar under the flag, the legacy bar otherwise — both feeding the same advancedFilter state.

Deferred (by your #968 split)

• Saved-filter sharing (folders/stars/scope + RLS) → PR 3. SavedFiltersPanel is intentionally not in this PR.
• Software-name autocomplete picker → needs a distinct-names endpoint (my parked fix(devices): software-picker server-side search + GIN trigram index #981); multi-select works via text entry until then.

Verification (local, node 22)

astro check 0 errors (775 files); full web suite 653 passing; eslint clean.

🤖 Generated with Claude Code

[bdunncompany]

Rebased onto current main now that #1012 (the #968 PR 1 filter engine) is merged. Dropped this branch's three superseded PR-1 commits (their filterEngine work is now in main via #1012) and kept only the two PR-2 web-UI commits. Web preflight green on node 22: astro check 0 errors, vitest 730/730. Ready for review.

[ToddHebebrand]

The chip-bar UX itself works — preview contract matches the merged #1012 backend, the add/remove/edit chip state machine is correct, no XSS, and runAction isn't required (the only network call is the read-only POST /filters/preview count). Bouncing on coherence, not correctness.

Must-fix 1 — this reinvents the existing filter component library. apps/web/src/components/filters/ already ships a full set: FilterBuilder.tsx, FieldSelector.tsx (searchable field dropdown), ValueInput.tsx (per-type value editor), OperatorSelector.tsx, FilterPreview.tsx, ConditionGroup/Row.tsx, SavedFilterList.tsx. This PR adds a parallel stack under devices/ — FilterSentenceBuilder.tsx, FilterAddDropdown.tsx, FilterValueEditor.tsx, FilterPreviewFooter.tsx — that re-solves the same problems, plus a hand-rolled click-outside mousedown close handler in three places (FilterAddDropdown.tsx, FilterChipBar.tsx, the help popover) that FieldSelector.tsx already standardizes. The chip-bar can be a distinct presentation, but the field dropdown / value editor / preview pieces should wrap the existing filters/ components rather than duplicate them.

Must-fix 2 — filterFields.ts:14 V2_FILTER_FIELDS is a third copy of the field catalog. The source of truth is the backend filterEngine.ts field set; web already has a second copy in filters/FilterBuilder.tsx (DEFAULT_FILTER_FIELDS); this adds a third. Three hand-maintained catalogs will drift — a field added backend-side silently won't appear, or will appear with the wrong operators (already visible: patches.pending / alerts.critical / system.rebootRequired are modeled here as enum {yes} but are boolean {equals,notEquals} in filterEngine.ts, so the UI can't express the negative case). Derive the catalog from one place.

Should-fix — flag uses a query param. The filter value correctly serializes to the #filtersV2= hash, but the on/off override is ?filtersV2=0/1 (filterUrl.ts:60), against CLAUDE.md's "use window.location.hash for transient UI state, never query params." If the override needs to be URL-addressable, put it in the hash too; the localStorage['breeze.filtersV2'] sticky form is fine as-is.

Happy to re-review once the new builder/value/dropdown pieces compose the filters/ library and the field catalog has a single owner.

[bdunncompany]

Thanks — all three addressed. Net diff is −62 lines (the changes remove duplication rather than add).

Must-fix 2 — single field catalog. New filters/filterFields.ts is the one canonical web mirror of the backend filterEngine (39 fields). Both FilterBuilder's DEFAULT_FILTER_FIELDS and the chip bar's V2_FILTER_FIELDS now re-export it — no third hand-copy. This also fixed the stale DEFAULT (it was the outdated copy): it had wrong dotted hierarchy keys (org.id vs the backend's orgId), a phantom patchCompliance, a 5-value status enum, and was missing 11 fields — its 7 consumers now get the correct catalog. Operator lists mirror the backend minus numeric between (the shared ValueInput renders between as a date-range picker only).

Must-fix 2 — the boolean predicates. patches.pending / alerts.critical / system.rebootRequired are now type: boolean (equals/notEquals), matching the backend, so the negative case is expressible.

Must-fix 1 — compose the filters/ library. FilterValueEditor now delegates standard value rendering (string/number/enum/boolean/date/multi) to the shared filters/ValueInput (~125 lines removed); it keeps only the genuinely chip-bar-specific editors that ValueInput doesn't have (org/site name pickers, software multi-select with counts). Bonus: this gains correct boolean (Yes/No) and between handling the chip-bar editor previously lacked. Added stable data-testids to ValueInput so it's testable. The hand-rolled click-outside mousedown handler in FieldSelector / FilterAddDropdown / the chip popover is now one shared hooks/useClickOutside, and the popover's Esc handler uses the existing useEscapeClose.

Should-fix — flag off query param. The on/off override moved from ?filtersV2= to #filtersV2Flag=on/off (a distinct hash key so it never collides with the filter value's #filtersV2=<base64>); localStorage sticky form unchanged. Added filterUrl tests.

Two I deliberately did NOT fold together (distinct responsibilities, not duplication): FilterAddDropdown is an add-a-filter affordance (onSelect(field)), not FieldSelector's edit-this-row's-field control (value+onChange); and FilterPreviewFooter fetches a live debounced match-count, whereas FilterPreview is presentational and renders a result list its parent already fetched. Wrapping those would contort components that legitimately differ — happy to revisit if you'd rather. Re-requesting review.

[ToddHebebrand]

Pushed a small API fix to the branch (d643bed2) found while UI-testing the chip bar — flagging since it touches the API, not your web code.

Symptom: the preview footer's "~N devices match" over-counted vs the filtered list — e.g. ~7 vs 6 for status = offline when scoped to a single org.

Root cause: pre-existing in the #1012-era endpoint, not this PR. POST /filters/preview (apps/api/src/routes/filters.ts:125,134) called getOrgIdsForAuth(auth) and summed totalCount across every accessible org, ignoring the ?orgId= that fetchWithAuth injects from the org-scope selection. A partner user viewing one org got a count that included matching devices in sibling orgs. Your chip bar is just the first consumer to surface it prominently.

Fix: honor the pinned orgId — scope to it when present (403 if the caller can't access it), span all accessible orgs only when it's absent (the "All orgs" scope, which omits the param). Regression tests added for the scoped count + the foreign-org 403.

Verified locally: API now returns 6 with ?orgId=<org> / 7 without; chip-bar table + preview agree; hash filter state round-trips on reload; quick-add chips, single field catalog, and Chip/Advanced toggle all work. filters tests 12/12, tsc clean.

Re-reviewing for merge once CI re-runs.