[Fleet] Allow users to customize columns within the Fleet UI

[nimarezainia]

Describe the feature:

We are often asked to add columns (or bring back, in case of tags) to the Fleet UI. There's a limited space (width) in the UI so adding relevant columns may not be feasible. Also there are fixed columns that we always need to have (such as host name or agent policy) but we are essentially making a choice for what the user wants to see. Which is not very platform like.

Additionally there is a lot of very rich data available in the local_metadata that Fleet has access to (which is also searchable).

Proposal

• [ ] Allow the Fleet UI columns be customizable
• [ ] Enable the user to source the column data from the local_metadata fleet has for each agent

This column customization would enable the users to build what is useful for them to see in the Fleet UI.

cc: @kpollich

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[kpollich]

This would be a great change! However I want to make clear some of the technical implications of doing this:

• We'd want to persist users' column selection somewhere. Should this be saved in the backend, and persisted for each user? Should this just be a localstorage key that's not shared across browser sessions for the same user?
• We'll need to consider limits to how many columns can be shown at a time, and potentially consider an overflow-based UI where the "inner" table can be scrolled independently from the browser window
• We'll definitely want to make Fleet's overall layout full-width instead of its current max-width implementation. This is something I think we had design mocks for at some point.
• Some data in local_metadata will be formatted vastly different from other data. Some fields will be short strings, others are booleans, others are longer messages or even nested properties. Handling this all in a generic column/table component will be challenging.

Overall, I think this would necessitate a full redesign + rewrite of Fleet's agent table UI. This is not something we could tackle as an enhancement to the existing implementation, I think.

[nimarezainia]

Thanks Kyle.

• Great point. IMO should be persistent per user or perhaps role
• the overflow idea is grand. As mentioned many of the columns should not be changeable, so there will be a limited space for custom columns.
• ++ on Full width
• Understood about the local_metadata. Do we not do this today? there are strings, integers maybe even booleans. Perhaps you are saying that this type is not stored in local_metadata for us to know what each field type exactly is.

[jen-huang]

I think this would necessitate a full redesign + rewrite of Fleet's agent table UI.

@nimarezainia I agree with this part from Kyle too. There are other enhancements filed related to our agent table, such as persisting other table state like filters, page, count per page, etc.

[jen-huang]

This is a potential duplicate: https://github.com/elastic/kibana/issues/133151