Proposal: chip-bar filter UI for /devices — working prototype in production

[bdunncompany]

Over the last couple of days I built and shipped (to my own self-hosted instance) a chip-bar filter UI for the Devices page. Posting it here because it works very well on real fleet data and I'd like to know whether you're interested in a PR.

What's in it

• Chip bar above the device list. Each filter becomes a removable chip. AND-only at the top level; nested groups via the sentence builder.
• Quick-add toggle chips for 9 canonical filters (one click adds, click again removes):
  • Online, Offline, Servers, Needs patches, Critical (active alert), Reboot needed, Not seen 7d, Low disk, Untagged
• 3 new virtual EXISTS filter fields (not stored columns; computed at query time):
  • patches.pending — EXISTS in device_patches with status='pending'
  • alerts.critical — EXISTS in alerts with status='active' AND severity='critical'
  • system.rebootRequired — EXISTS in patch_job_results with reboot_required=true AND rebooted_at IS NULL
• Software multi-select with hasAny / hasAll via a softwareInventory EXISTS subquery and a fleet-wide picker (GET /devices/software/distinct returns the distinct list scoped to the caller's accessible orgs)
• Saved filters get folders, stars, and scope (private / org / partner) so MSP techs can share canonical filters per org without polluting the global list
• Filter preview footer: count + sample hostnames while you build, before applying (POST /devices/filter-preview returns {count, sampleHostnames, matchingIds[]})

Compatibility with the All-orgs toggle

The new filter-preview fetch passes skipOrgIdInjection: orgScope === 'all' to the api auth helper, so the chip-bar filter respects the existing Current-org / All-orgs scope toggle from DevicesPage.tsx. Filter results flow through the same scopedDevices memo so client-side scope filtering stays consistent.

Scope

• 26 modified/new files (web + api), 1 new additive migration, 2 new API routes
• Migration adds saved_filter_folders, saved_filter_stars, plus columns on saved_filters (scope, folder_id, last_used_at, use_count, icon, color). Idempotent, no destructive ALTERs.
• New routes are auth-gated (organization+ scope, DEVICES_READ permission) and additive (no replacement)
• filterEngine.ts gains a small handler block for the 3 virtual EXISTS fields + software multi-select; existing field handling unchanged

Test coverage

• 31 api filter tests (filterPreview, softwareDistinct, filterEngine virtual fields, software multi-select)
• 85 web component tests (FilterChipBar, QuickAddChips toggle behavior, scope toggle regression)
• Plus end-to-end smoke on a restored production pg_dump (193 → 194 migrations, ensureAppRole + new tables verified, routes return auth-gated 401)
• api tsc clean, web astro check clean (0 errors, 0 warnings)

Status

Deployed to my self-hosted instance — running on a fork branch off vps-deploy-2026-05-21, with the filter feature initially gated by ?filtersV2=1 for safe rollout and now flipped default-on (opt-out via ?filtersV2=0). ~190 device fleet, working as expected including the AllOrgs / Current-org toggle integration.

Screenshots:

Chip bar with the software multi-select picker open:

Chip bar with three active conditions (Has Software, Organization, Status) composed together; quick-add toggles below:

Advanced view with several options selected:

Open questions

1. Is this a feature you'd want upstream? If yes, I can prep a PR against main. Most likely path is to split it into 2-3 small PRs (api routes + service, schema migration, web UI) for review clarity.
2. The filtersV2 flag — keep it as an opt-in for some release window, or just replace the existing DeviceFilterBar?
3. Anything in the design above you'd want changed before a PR lands?

Happy to walk through the design on a call or open the PR(s) for review. Code is in the worktree feat/vps-filter-port on my fork; can rebase onto main on request.

[ToddHebebrand]

This is excellent work, and the fact that it's already running default-on against a ~190-device fleet is the best possible argument for it. Yes — I want this upstream. Answers to your three questions, plus one correction to a framing in your write-up.

Q1 — yes, want it. Take it in two bites, not one. The reason is tenant isolation, not size. Everything except the saved-filter sharing layer builds directly on infrastructure already in main:

• filterEngine.ts (apps/api/src/services/filterEngine.ts) already compiles a filter AST to SQL across 30+ fields including software.*, with a handler block built to extend — your 3 virtual EXISTS fields slot straight in.
• /filters/preview already exists and already returns matching IDs.
• The current advanced filter already does exactly your model: POST /filters/preview → matchingIds[] → client-side Set intersection (DeviceList.tsx:174,263, serverFilterIds).

So the chip bar + quick-add + 3 virtual fields + software multi-select are a UI layer plus a few additive filterEngine fields on top of plumbing that already works your way. That's PR 1 (api fields + service) and PR 2 (web UI) — both low-risk, land them first.

Defer the saved-filter sharing system to its own PR (your PR 3). saved_filter_folders, saved_filter_stars, and especially scope: private/org/partner on saved_filters are new tenant-scoped tables, and partner-scope is the one that needs care. That PR has to carry the full RLS treatment per CLAUDE.md: policies in the same migration that creates the tables, the right tenancy shape per table (partner-axis is Shape 3 — flat breeze_has_partner_access, never tree traversal), an entry in the relevant allowlist in rls-coverage.integration.test.ts, and a cross-tenant insert verified to fail as breeze_app. None of it is hard, but it's the part I want to review on its own rather than buried in a 26-file UI diff. Folders/stars are simpler (likely user-id scoped, Shape 6) but same discipline.

Q2 — keep filtersV2 for one release window. Don't rip out DeviceFilterBar until the new path has run on a non-trivial fleet through an upgrade. Flip default-on, opt-out via the flag, then remove the flag and the old bar in a follow-up once it's proven.

One correction so we're aligned on scale. Your write-up says the filter flows through the filteredDevices/scopedDevices memo to stay consistent with the All-orgs toggle — that's correct, and it's worth being explicit that this is the existing page architecture, not something your PR introduces: fetchAllDevices (apps/web/src/lib/devicesFetch.ts:108) walks the cursor and accumulates the entire accessible fleet into the browser (~40k cap, then a truncation toast), and all filtering/sorting/paging is client-side over that array (DeviceList.tsx:258, :337). So the chip bar inherits the page's existing in-browser ceiling — it doesn't create a new one, and it doesn't conflict with the keyset cursor (#777/#778), which is there for transport stability, not lazy loading. When we eventually move the page to true server-side lazy loading, the chip predicates already live in filterEngine server-side, so that migration helps filters rather than fighting them. Nothing for you to change — just naming it so a reviewer doesn't flag "this loads everything client-side" as a regression in your PR when it's the status quo.

Q3 — design changes: only the split above. Keep the EXISTS fields, but add the partial indexes they imply in the same migration so they stay cheap as fleets grow. Verified the column names against schema/patches.ts + schema/alerts.ts — lead each with device_id since the subqueries correlate on it:

CREATE INDEX IF NOT EXISTS idx_device_patches_pending
  ON device_patches (device_id) WHERE status = 'pending';

CREATE INDEX IF NOT EXISTS idx_alerts_active_critical
  ON alerts (device_id) WHERE status = 'active' AND severity = 'critical';

CREATE INDEX IF NOT EXISTS idx_patch_job_results_reboot_pending
  ON patch_job_results (device_id) WHERE reboot_required = true AND rebooted_at IS NULL;

Otherwise the design is sound.

Go ahead and open PR 1 (api) against main whenever you're ready — rebase onto current main first, since filterEngine and /filters/preview have moved since your vps-deploy-2026-05-21 fork point. Happy to do a design pass on the saved-filter migration before you cut it if that saves you a round-trip.

[ToddHebebrand]

Shipped. The chip-bar filter UI landed across two PRs: #1012 (the device-filter engine + /filters/preview count endpoint, merged 2026-05-31) and #1013 (the chip-bar/Advanced UI on /devices, merged 2026-06-08). Final form reuses the canonical components/filters/ lib + single field catalog, keeps filter state in window.location.hash (#filtersV2=), and previews live counts as you build. Verified in-browser (quick-add chips filter client-side, hash round-trips on reload). Thanks for the prototype — closing as resolved.