UI - use new db user settings to persist user's host table column preferences

[jacobshandling]

For #25032

• Add new include_ui_settings query param to GET /me calls

• Use new settings in response to set settings into UI context

• On hosts page, use that context, if present, to set which columns are hidden. Fallback to a default set of hidden columns.

• When updating visible columns, persist preference via PATCH to /users/:id with a new settings payload

• Changes file added for user-visible changes in changes/

• Manual QA for all new/changed functionality

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.

Project coverage is 63.84%. Comparing base (cac3e2f) to head (472498b).
Report is 24 commits behind head on main.

Files with missing lines	Patch %	Lines
frontend/context/app.tsx	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #25185      +/-   ##
==========================================
- Coverage   63.85%   63.84%   -0.01%     
==========================================
  Files        1616     1616              
  Lines      153833   153847      +14     
  Branches     3939     3993      +54     
==========================================
- Hits        98231    98229       -2     
- Misses      47789    47805      +16     
  Partials     7813     7813              

Flag	Coverage Δ
frontend	53.20% <0.00%> (-0.08%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jacobshandling]

All changes in this file are cleanup, no logic updates

[sgress454]

Tested locally, works great 👍

Can you say more about the updates to the registration and team management pages?

[sgress454]

I'm a bit torn on this, as it means breaking existing functionality for users. I confirmed that we're not clearing localstorage on logout, so the columns do persist between sessions (just not between browsers, or in incognito mode). On the other hand we wouldn't want to support this forever as eventually everyone will be using the new strategy. If it sparks a riot we can put it back in a patch, but likely no one will notice.

[jacobshandling]

That was my thinking too. We could include fallback behavior to use local storage, but I don't really see the scenario where the user has logged in, is actively using Fleet, and suddenly the server is somehow unavailable for this specific functionality.

[sgress454]

I wasn't think of it as fallback behavior as much as, people right now have their columns set up and they're going to disappear when this deploys.

[jacobshandling]

Aaah, I see

[jacobshandling]

We need a UI migration 🙂

[jacobshandling]

We could, in this initial rollout, check for local storage settings, and if present, immediately send them to the server to persist and set them as current UI context, then down the line remove that code

[jacobshandling]

(or not remove it I suppose, but there would be no reason for anything to present in local storage after not too long)

[sgress454]

We could, in this initial rollout, check for local storage settings, and if present, immediately send them to the server to persist and set them as current UI context, then down the line remove that code

This is probably the way. It seems a bit heavy handed but considering the original ask, we'd ideally like the user to see the columns they expect and then also see them in another browser / incognito mode, without having to do any action to trigger persistence.

[jacobshandling]

Sounds like a plan

[jacobshandling]

Can you say more about the updates to the registration and team management pages?

@sgress454 since they're already making calls to the /me endpoint, figured might as well update the settings context with those responses while we're getting them, nothing more specific than that.