Allow objects/flatten fields in saved objects management

[timroes]

Currently the saved object management view, takes all fields in the saved object and put them into an individual field in the list. We often store more complex JSON (that should go into one JSON field) in saved objects. Earlier we tended to do that via putting a stringified version of that JSON into a keyword field. Nowadays we use the proper approach and use rather an (unindexed) object field or a flattened field for it.

This causes the problem, that if we'd try to create saved object management views for those saved objects, they will list out every key in that JSON as an own field, leading to something like the following:

This is not really usable. We should have a mechanism to allow showing those object/flattened fields still as one JSON editor in the saved object view.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

Issue is, we don't have any way to 'detect' which nested fields should be 'expanded', and which one should not (or could we guess that from the mapping @timroes ?)

We could add an 'expand/toggle' feature on nested fields, to allow the user to choose how he wants to visualize the SO fields, however, the user would still need to expand and/or collapse the fields every time he goes to the so edition page.

[timroes]

@pgayvallet I think it would already be fine, if you can manually specify (within the registration of the management part) which part of the saved object should be treated as JSON. I think we wouldn't even necessarily need to automatically detect that via mappings.

I think a pure "expand" wouldn't help that case, because we'll still need to make sure it's represented as JSON not just collapsed. You can see in the above screenshots, that we have some UUIDs in there, so basically the JSON contains a list of data sources. If a user would be able to edit that, they should also be able to edit the whole list of datasources, which doesn't work if we already put an individual field per property. Also (same for e.g. visStates) there are tons of properties that might not be in the saved object (because the user doesn't configure them), but could still be added via the JSON view.

[pgayvallet]

if you can manually specify (within the registration of the management part) which part of the saved object should be treated as JSON. I think we wouldn't even necessarily need to automatically detect that via mappings.

That seems like a pragmatic solution, SGTM.

[timroes]

I think we should no longer address this, since we seem to have agreement, that #59588 is the way we want to go (which makes this issue redundant).