Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make saved object import / export work with any type of saved object #34862

Closed
mikecote opened this issue Apr 10, 2019 · 7 comments · Fixed by #34896
Closed

Make saved object import / export work with any type of saved object #34862

mikecote opened this issue Apr 10, 2019 · 7 comments · Fixed by #34896
Assignees
Labels
Feature:Saved Objects Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@mikecote
Copy link
Contributor

mikecote commented Apr 10, 2019

Now that new APIs are used for saved object import / export, there is a need to allow any type of saved object to be included.

Once completed, this should solve:

@mikecote mikecote added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:Saved Objects labels Apr 10, 2019
@mikecote mikecote self-assigned this Apr 10, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform

@mikecote
Copy link
Contributor Author

There's a few options we can go with for the initial phase:

For each option, the following would apply:

  • Tooltips for non clickable link titles explaining why the saved object can't be edited
  • An API to fetch which types of saved object are import / exportable (unless / until we can do this with uiExports)
  • Go through each app and try to add a title, icon and view in app url.

Option 1

Create an API to fetch extra saved object information from configured plugins, pass in type and id combinations to get the results. uiExports would contain functions like getTitle, getIcon, getEditUrl and getNavUrl.

API example

  • /api/saved_objects/_get_info: Pass in type and id combinations

Option 2

Create a new management API that wraps the _find API but automatically injects the extra necessary information in a single API call. uiExports would contain functions like getTitle, getIcon, getEditUrl and getNavUrl.

API example

  • /api/kibana/management/saved_objects/_find: Takes the same parameters as the regular _find API but automatically adds the extra information for each saved object.
  • /api/kibana/management/saved_objects/_relationships: Same behaviour as now but automatically adds the extra information for each saved object.

Option 3

Keep the code as is in the front end. There are currently central functions in the management code to get edit url and such. Document the steps each app that couldn't be converted initially would need to do in order to enhance the user experience.

@epixa thoughts? I'm tempted to explore option 2.

@epixa
Copy link
Contributor

epixa commented Apr 10, 2019

I'm comfortable with option 2 as well.

@nreese
Copy link
Contributor

nreese commented Apr 10, 2019

@mikecote Will this also add support for map saved objects?

#28037

@mikecote
Copy link
Contributor Author

@nreese correct, I will resolve that issue once the changes are merged.

@mikecote
Copy link
Contributor Author

I have chosen the following types to be included in management UI for import / export:

[
  'config',
  'graph-workspace',
  'map',
  'canvas-workpad',
  'index-pattern',
  'visualization',
  'search',
  'dashboard',
  'url',
]

The following have been left out:

[
  'telemetry',
  'space',
  'ml-telemetry',
  'apm-telemetry',
  'maps-telemetry',
  'infrastructure-ui-source',
  'upgrade-assistant-reindex-operation',
  'upgrade-assistant-telemetry',
  'server',
  'kql-telemetry',
  'sample-data-telemetry',
  'timelion-sheet', // Now part of visualization object?
  'ui-metric'
]

@epixa questions:

  • Did I miss any types that should be included?
  • Are we keeping the opt-in by default behaviour? The object types will show up by default until configured not to via savedObjectSchemas[type].importExportable: false in uiExports.

@epixa
Copy link
Contributor

epixa commented Apr 16, 2019

Did I miss any types that should be included?

Not that I can think of.

Are we keeping the opt-in by default behaviour? The object types will show up by default until configured not to via savedObjectSchemas[type].importExportable: false in uiExports

Might as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Saved Objects Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants