Devices list: per-user column visibility + reorder (Discussion #56 follow-up)

[bdunncompany]

What

Make the columns shown on the Devices list user-controlled (which to show + what order). Deployed and running today at https://breeze.bdunn.com behind the existing auth. Posting this for review/green-light before opening the PR.

Why

Devices list today has a fixed 9-column set. Operators with different roles need different things visible:

• Help-desk wants Hostname / Last User / Last Seen up front.
• Patching-focused folks want OS Version / Architecture / Patch Compliance.
• Asset-management wants Serial Number / Manufacturer / Model.

Adding all of those as always-on columns balloons row width on small displays. A per-user toggle + reorder lets each operator keep the same surface but tune what's visible.

Where (code)

• apps/web/src/components/devices/columnVisibility.ts (new) — single source of truth for column IDs, labels, default-visible set; localStorage read/write helpers.
• apps/web/src/components/devices/osIcons.tsx (new) — inline SVG OS glyphs for the compact OS column.
• apps/web/src/components/devices/DeviceList.tsx — wires the toggle menu, persists user choice, renders columns in the user's chosen order.

Branch (fork): feat/devices-list-column-visibility on bdunncompany/breeze.

Behavior

• Two non-togglable columns: row-select checkbox (always first) and the row-actions menu (always last).
• 9 togglable columns visible by default — the pre-feature set so existing users see zero change on first render.
• 9 additional columns available off-by-default: Last User, Uptime, OS Build, Architecture, Enrolled Date, CPU model, RAM total, Disk total, Tags. (More can be slotted in cheaply later.)
• A "Columns" button next to the search bar opens a popover with per-column checkboxes + up/down arrows to reorder.
• Choices persist per-browser via localStorage under two keys (visibility-set + order-list). Two keys (not one combined value) so a future column added to COLUMN_IDS doesn't get retroactively marked visible for users who had toggled the set when the catalog was smaller.
• Empty stored set falls back to defaults (an empty table is worse UX than the pre-feature view).
• SSR-safe (typeof window guards + try/catch for Safari private-mode SecurityError).

Status pill

Same change touches the status pill: the column now shows compact glyphs (Up / Down / Maint / Decom / Quar / Upd) with the long form on the title attribute, so a row at 1280px wide stays readable and the long form is still one hover away. This is part of the same PR because the column-visibility work makes status optional — when shown, it should be tight.

Tests

• Unit: columnVisibility.ts — read/write/default/malformed/SSR paths.
• Component: DeviceList renders only visible columns, persists reorder, restores from localStorage on remount.

(All green locally on the branch; happy to paste vitest output in the PR.)

Open questions before PR

1. Default-visible set — is "the existing 9" the right floor, or do you want a smaller default + opt-in for more?
2. The Tags column renders space-separated chips when visible. Acceptable styling pattern, or want me to render as comma-separated text to match the others?
3. Two keys vs one — defensible for the reason above, but happy to collapse if you'd rather just bump a schema version.

Reasonably close to the WoL pattern (Discussion #694 → PR #703) — opening the Discussion first per your usual flow. PR ready to push as soon as you green-light.

cc @ToddHebebrand

[ToddHebebrand]

Thanks @bdunncompany — PR #737 received and tracked. Will respond on the PR with decisions on the three open questions (default-visible set, Tags chip vs text, two-key vs one-key localStorage). Leaving this discussion open until #737 merges.

[bdunncompany]

Friendly follow-up — circling back on the three open questions from this discussion: (1) default-visible column set size, (2) Tags chips vs text, (3) two-keys vs one-key localStorage.

Happy to go whichever direction you prefer; flagging because PR #737 is otherwise ready to come out of draft once those land. I'll also need a rebase on top of #778's fetchAllDevices rewrite (mechanical but real — your earlier triage flagged this), so I can sequence that after your answers.

No rush — just keeping the loop closed.

[ToddHebebrand]

Thanks for the patience — decisions on all three so you can come out of draft.

1. Default-visible set → keep the existing 9. It's the only choice that's a true no-op on upgrade: nobody opens Devices to find their layout rearranged. A lean-default + opt-in is a nicer ideal, but it's a silent behavior change for 100% of existing users to buy an aesthetic win — if we ever want that, it's a separate, announced change. Ship the 9 as the floor.

2. Tags → chips, but cap them. Tags are the one genuinely categorical column, and chips scan better than comma text — "match the other columns" isn't persuasive when the data type is different. The only real risk is row-height/width blowup, so cap visible chips and collapse the rest into a +N (full list on title hover, same trick you used for the status pill). Chips + overflow guard, not unbounded chips.

3. Storage → one key, not two — but the reason isn't "drift." Your two-key instinct is defensible and the code degrades gracefully, so this is a cleanup ask, not a bug. The thing I'd change: order-list and visibility-set are really one ordered list wearing two hats — order is the array order, visibility is a flag on each entry:

// breeze.devices.columns
{ "v": 1, "columns": [ { "id": "hostname", "visible": true }, { "id": "tags", "visible": false } ] }

Collapsing them means one atomic setItem (no partial-write window where one key updates and the other throws on a Safari SecurityError), and it makes the new-column protection explicit. That protection was never the key split doing the work — it's merge-on-read, which you need either way:

• drop any stored id no longer in the catalog,
• append any catalog id missing from storage, in catalog order, inheriting the catalog's default-visible flag (so a future "Compliance" column ships visible if we say so — not silently forced on, not silently hidden),
• empty/malformed/SSR → full catalog defaults (you already have this).

Same guarantee your two keys were protecting, atomic, single source of truth. Keep the v int for cheap future migrations.

Net: green-light on (1) and (2) as-built; (3) is the one change — fold the two keys into the versioned ordered list above. Rebase on #778's fetchAllDevices rewrite, then pull it out of draft and I'll do the PR pass.

[ToddHebebrand]

Shipped in #737 (merged 2026-05-31). Per-user column visibility on the Devices list, persisted in a single versioned breeze.devices.columns localStorage key with merge-on-read (new columns appear, removed ones drop), matching the design we settled on in this thread. Closing as resolved.