Server search/filter, coloured tag pills, and tag-tree grouping across all three surfaces

[jakemorgangit]

Hi Erik — a feature proposal for finding and organising servers as the monitored list grows. Flagging up front what already exists so this is framed as extend + bring to parity, not reinvent.

What's there today

• Viewer already has hierarchical server tags (config.server_tags with parent_id / sort_order, many-to-many via server_tag_map), and renders them as a collapsible tag tree in the sidebar (servers nested under tag headers). Nice foundation.
• Tags have no colour (no colour column), are not shown as pills, and don't appear on the Overview cards.
• Lite and the web viewer have no tag concept at all — no tree, no grouping.
• Search / filter by server name (or tag) does not exist on any surface — the Viewer's FleetView even reserves a seam for it, but it's unbuilt. Lite's Overview and the web fleet page have a sort control only.

A bug I hit while auditing this: tag editing silently fails for the viewer role

The "Assign Tags" submenu (and create/rename/delete) appears to do nothing on a managed store. The wiring is fine — AssignTag_Click calls AssignServerTagAsync and reloads — but every tag write routes through ExecuteWriteAsync, and the viewer role has no write grant on config.server_tags / config.server_tag_map (neither provision-roles.sql nor DarlingManagedRoles grants them — custom_views got its viewer write grant, the tag tables were missed). So on a store where the Viewer connects as the least-privilege viewer role, the INSERT hits 42501, ExecuteWriteAsync degrades it to ViewerReadOnlyException, and the click's catch logs "Assign/unassign failed" and shows nothing. Net effect: tags are effectively read-only from the Viewer on any provisioned store.

Happy to send this as a tiny standalone fix (add the viewer INSERT/UPDATE/DELETE grants on the two tag tables, mirroring the custom_views grant) ahead of the feature below, if you'd prefer to decouple it.

The gap

On a large fleet you can't quickly find a server, and — even where tags exist (the Viewer) — they're editable only in theory, invisible except as sidebar grouping, and absent from Lite and the web entirely. DEV/PROD/TEST/etc. live only in people's heads or server names.

Proposal (suggested as two stages)

Stage 1 — search/filter (self-contained, high value). A search box on the servers list and the overview/dashboard, on all three surfaces, filtering by server name (and by tag where tags exist). In the Viewer it slots into the FleetView.Rebuild seam already reserved for it. No schema change; ships independently.

Stage 2 — finish + spread tags.

• Fix the viewer-role grant gap above so tag editing actually persists.
• Add a colour to the tag model — a nullable colour column, auto-assigned from a rotating palette on tag creation and user-overridable — and render a server's tags as distinct coloured pills on the server cards / overview.
• Bring tags to Lite and the web viewer: a tag model mirroring Darling's hierarchical many-to-many shape (cross-surface parity), the Viewer's sidebar tag-tree grouping brought over as opt-in drill-down (SSMS Object-Explorer style), and pills.

Search then narrows within the tree; pills annotate each card.

Per-surface scope

• Viewer: add a colour column to config.server_tags (migration) + a colour picker in the tag UI; render tags as pills on the Overview cards (today they only group the sidebar tree); add the search box at the Rebuild seam.
• Lite: greenfield — a tag model (DuckDB tables mirroring Darling's shape for parity), a manage-tags UI, tree grouping + pills on the Overview, and the search box next to the existing sort control.
• Web: /api/fleet gains tag data (it emits none today); the fleet page gains a search input, tag pills on the cards, and tree/group rendering.

Open questions

1. Stage it as above, or one PR? And would you want the viewer-grant fix as its own tiny standalone PR first (it's a real bug independent of the feature)?
2. Colour — a nullable column on config.server_tags, auto-assigned + user-overridable as I've proposed? Any palette/convention to match, or a preferred storage shape?
3. Lite tag model — mirror Darling's hierarchical many-to-many shape for parity (my assumption), or keep Lite simpler?
4. Web tags — read-only on the web with assignment staying in the desktop apps (my assumption), or editable there too?

Happy to shape any of it to fit the project's direction.

[erikdarlingdata]

Thanks for the thorough audit — the framing ("extend + bring to parity") and the per-surface inventory are both accurate, and I verified every factual claim against dev: the Viewer's hierarchical tags + tree, no colour anywhere, no tags in Lite or /api/fleet, no search on any surface, and the FleetView seam comment is exactly where you said it is.

On the bug: your diagnosis of the symptom is confirmed, but the fix goes the other way. The failure chain is real — every tag write routes through ExecuteWriteAsync on the viewer-role connection, there are no grants on config.server_tags/server_tag_map, so 42501 → degraded → a status-bar line under working-looking menus. But the grant gap is deliberate: the viewer role is a read-only seat whose ONLY write is config.custom_views, and tags are shared fleet configuration — they stay admin-seat-edited. The actual defect is that the tag UI shipped without the IsReadOnly gate every other write surface carries (compare RecommendationsGenerateButton.IsEnabled = !_dataService.IsReadOnly; the tag files have zero references to the probe).

Fix is up as #2011: all three tag entry points (header context menu, Assign Tags submenu, Manage Tags) now disable on a read-only seat with a tooltip saying why — your complaint was the silence, and a bare grey-out would just be quieter silence — via ToolTipService.SetShowOnDisabled, since WPF hides tooltips on disabled elements. Admin-seat and self-managed single-connection stores keep editing tags as before. So for your Stage 2 list: tag editing stays where the role model puts it, which doesn't constrain the rest of the proposal — colour, pills, search, and read-side parity are all read-path features.

The design questions (staging, colour storage, the Lite tag model, web editability) deserve a considered answer — coming separately.

[erikdarlingdata]

Answers to the open questions — the proposal is welcome, staged roughly as you suggested:

1. Staging. Yes to two stages, and yes to decoupling further. Stage 1 (search/filter) is greenlit as its own PR — self-contained, no schema, and it slots into the FleetView.Rebuild seam that was reserved for exactly this. Ship it first. For Stage 2, split it again: (2a) colour + pills on the Viewer is small (one nullable column + rendering) and can follow quickly; (2b) Lite/web tag parity is the big lift and should be its own issue/PR so it doesn't hold the rest hostage. The grant-gap part of your Stage 2 list is already resolved, the other way: #2011 (merged shortly) gates the tag editors on the read-only probe instead of granting writes — the viewer role stays read-only by design (its only write is config.custom_views), and tags are shared fleet configuration edited from the admin seat. None of the rest of your proposal needs viewer-role writes: colour, pills, search, and parity are all read-path.

2. Colour. Your shape is right: a nullable colour column on config.server_tags, auto-assigned from a rotating palette at creation, user-overridable. Specifics to match the house: store it as #RRGGBB text (nullable; NULL renders a neutral pill, and existing tags stay NULL until touched — the migration adds the column and backfills nothing); assign from a fixed palette of theme-safe colours that read on BOTH the dark and light themes (the theme-parity guard will care — check contrast against the pill's text brush in each theme rather than hand-picking against one); rotate by tag id rather than randomly so re-creating the same tree gives stable colours. Claim the migration number at PR time — they have been moving quickly this week.

3. Lite tag model. Mirror Darling's hierarchical many-to-many shape, as you assumed. Parity-of-shape is how the twins stay honest everywhere else in this codebase (same statistics, same views, same semantics), and a simpler Lite model would fork the mental model and block any future import/export between the two.

4. Web tags. Read-only on the web, assignment stays in the desktop apps — as you assumed. That now also follows from the role answer above: the web viewer rides the least-privilege seat, and /api/fleet gaining tag DATA is purely a read. Pills + search + grouping on the web, no editors.

One process note for the PRs: base them on dev, CHANGELOG entry with a bottom link ref, tests in the same PR — and for anything touching the sidebar/tree rendering, the theme-parity guard and the FleetView unit seams are the tests to extend. Looking forward to Stage 1.

[jakemorgangit]

Stage 2b of #2008 — the parity lift, following stage 1 (search, #2014) and stage 2a (Viewer tag colour + pills, #2015). Brings the tag concept that already exists in the Darling Viewer to the two surfaces that lack it, on the read side. Flagging what's there so this stays extend + parity.

What exists now

• Viewer: hierarchical tags (config.server_tags + server_tag_map), a sidebar tag tree, per-tag colour (#RRGGBB, 2a), coloured pills on the Overview.
• Lite: no tag concept.
• Web: no tags — /api/fleet emits none.
• Already shared (from 1/2a, so 2b reuses rather than rebuilds): ServerOverviewFilter (the name/tag match rule) and TagColorPalette (swatches + id-rotation) both in PerformanceMonitor.Ui.

Proposed plan — two PRs, Lite first

Splitting further as you did with 1/2a: the two halves have different risk profiles (Lite changes schema; web is pure read-path), so they shouldn't ride together.

2b-i — Lite (the lift). A tag model in the Lite store mirroring Darling's shape per your parity answer — DuckDB server_tags (id / name / parent_id / sort_order / colour) + server_tag_map. A Manage Tags window ported from the Viewer's, reusing TagColorPalette for auto-assign + the swatch picker. Tree grouping (opt-in drill-down) + coloured pills on the Overview. Stage-1 search extended to match tag names — ServerOverviewFilter already takes multiple fields, so that's wiring, not new logic. Lite is single-connection with the user's own credentials (no read-only role), so tag editing is simply enabled — no #2011-style gate.

2b-ii — Web (read-only). /api/fleet gains per-server tag data (name + colour) — a pure read; assignment stays in the desktop apps, per your answer. The fleet page gains tag pills and search by tag. Kept deliberately small.

One open question

The SSMS-style tag tree on the web is the lowest value-per-effort piece — pills + search deliver most of it. I've scoped 2b-ii to pills + search and left the web tree as an optional later slice. Happy to fold it into 2b-ii instead if you'd rather it land together.

Sequencing: 2b-i starts once 2a (#2015) merges, so the shared TagColorPalette / ServerOverviewFilter bits are on dev first.