[META][AppEx - AnalyticsXP] Audit use of savedObject.client

[thomasneirynck]

No code under public/ should use the saved-objects client.

ie. there should be no usage of coreStart.savedObjects.client

• Presentations
• Visualizations
• DataDiscovery

If there is usage of the , and it cannot be replaced by onboarding on the content-management system (#157043) , please create a corresponding issue or PR for its removal.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[thomasneirynck]

We have identified a .clone() usage in Dashboard, which is still required to clone saved-searches generically.

Will need a proposal for fix/work-around/solution/..

cc @ThomThomson @davismcphee

[ThomThomson]

Noting here additional info regarding the clone usage in Dashboard.

Problem:

Currently when cloning a panel on Dashboard there are three processes which can be followed:
1: If the panel to be cloned can be by value or by reference, unlink the panel and clone it by value
2: If the panel to be cloned has a saved object ID but cannot be used by value, clone the saved object itself and link the new panel to the new saved object.
3: If the panel is already by value, or cannot be used by reference, clone the panel by value.

The second option is a problem for serverless because it requires a generic usage of the saved objects client to clone an arbitrary type of saved object. This is also a UX problem because it can create cruft - many copies of the same saved object - in the visualize library.

Additionally, most panel types are either by value only, like log stream or the ML embeddables, or by value / by reference like Lens, TSVB, Visualize, Maps etc. This means that option 2 is only used when cloning a saved search.

Potential Solutions:

1. We could build a new generic clone API route that is only used when cloning a saved search. This would require a lot of work, and wouldn't solve the problem of many duplicated library items.
2. We could remove the usage of the saved object client for cloning and disallow cloning on the saved search level. This would introduce a functionality regression.
3. We could leave the saved object client usage in place as is until Saved Searches can be created by value. This way, cloning a saved search would use option 1 instead of option 2. Then when it is possible to clone a saved search by value we will be able to remove the code entirely.

So far, the Presentation & Data Discovery teams have aligned around potential solution 3.

[thomasneirynck]

usage removed, closing pending #159109

[ThomThomson]

Closing this because the problem outlined in this comment has been fixed by #164108