Saved object export/import API

[nreese]

There is a need for an export API that exports saved objects with all dependent saved objects.

Export

curl -XPOST '<KIBANA_BASE_URL>/api/saved_objects/export' --header "kbn-xsrf: kibana" --header "Content-Type: application/json" -d '{"savedObjects":[{"id": "67536cc0-1677-11e8-bfb1-eb70a3f0b53c", "type": "dashboard"]}'

Implementation notes

There is an existing API, /api/kibana/dashboards/export, for importing/exporting dashboards. Once a generic export API exists, the dashboard export/import API needs to be deprecated and removed in 7.0.

The logic for exporting a saved object's dependencies needs to be accessible by other places in Kibana (OLS is one example). As such, it makes sense to add a method getDependents to saved_object_client that takes (type, id) and returns an array of saved objects containing all dependents (including multiple generations) for the parent saved object.

The logic to gather dependents for a saved object type needs to be pluggable. Plugins can define their own saved object types. Plugins must also be able to define a function that gathers dependents.

The logic to gather dependents for a visualization type needs to be pluggable. For example, Controls visualization type will need a way of registering a function to fetch dependents because it functions differently from other visualization types and references Index Patterns inside 'params.controls'.

cc @bmcconaghy @kobelb @stacey-gammon @epixa @AlonaNadler

[epixa]

@elastic/kibana-platform

[conmurray]

Hi guys,

I've come here from #17542.
My particular problem for my use case is that because the kibanaSavedObjectMeta.searchSourceJSON now references the index by an ID and not by the actual index name, everything is broken when I delete an index and recreate it again with the same name but it gets given a new ID.

[epixa]

@conmurray You can manually specify an id as well. In the UI, there's a toggle to expand the advanced options that will show you the id field.

[conmurray]

Thanks, however it's not the ID that is causing the problem for my users. It's the fact that one has to now use an index ID when previously we referenced the index by its name in the Json.

[epixa]

@conmurray It's still not clear to me how needing to use an index id is a problem given that you have full control over the index pattern id and thus could make it anything you want. I'd love to hear more about your use case to figure out if there's a workaround for you, but it doesn't sound like the import/export API is what you need. Can you start a discussion on the Kibana forums and explain your use case in more detail and exactly where the id becomes a problem? Link back to this issue so other folks have some context. https://discuss.elastic.co/c/kibana

[conmurray]

Sure thing...
I've put the details in here
https://discuss.elastic.co/t/kibana-index-id-now-references-an-id-and-not-a/136175

[alexfrancoeur]

Can this be closed with @mikecote's changes?

[mikecote]

@alexfrancoeur I think there's still a need to deprecate the dashboard export API and eventually remove it. We could use this issue for this or create a new one?

[rudolf]

Since #41439 tracks the deprecation of the old API, I'm going to go ahead and close this issue.