Kibana: Management Saved Objects overhaul

[tylersmalley]

When creating the saved objects API, I played around with directly using the Saved Objects Client within the Management Saved Objects page instead of using Courier. While this turned out to be a larger undertaking than we had time for, I feel there are advantages to overhaul this page now that the API exists.

Here are some goals which I believe we should solve:

Ability to import/export all Saved Object types

Currently, one is only able to export Dashboards, Searches, and Visualizations. This limited ability can give the illusion that it's all which is required to backup the Kibana state. There have been issues raised to export remaining objects under the Kibana index including but not limited to advanced settings, Timelion sheets, and Index Patterns.

• config
  
  
  
  • Advanced Settings
  
  
  • https://github.com/elastic/kibana/issues/4265
  
  
• dashboard
  
  
  
  • Saved Dashboards
  
  
• graph-workspace
  
  
  
  • Saved Graph Workspace
  
  
• index-pattern
  
  
  
  • Saved Index Patterns
  
  
  • https://github.com/elastic/kibana/issues/4288
  
  
  • https://github.com/elastic/kibana/issues/5155
  
  
  • https://github.com/elastic/kibana/issues/13002
  
  
• search
  
  
  
  • Saved Searches
  
  
• timelion-sheet
  
  
  
  • Saved Timelion Sheets
  
  
  • https://github.com/elastic/kibana/issues/9107
  
  
• url
  
  
  
  • Short URL’s
  
  
  • https://github.com/elastic/kibana/issues/12365
  
  
• visualization
  
  
  
  • Saved Visualizations
  
  

Per-object type editing form

When editing a saved object, we currently use a generalized form which determines the input to use for each field. If we were to instead create a form per type, it would allow us to improve this UI. For example, when editing a dashboard we could provide a dropdown of saved searches instead of a text input for the saved search id.

True paginated results

We currently fetch 100 objects for each type, in parallel and provide an in-browser pagination. We now have the ability to easily manage pagination through the API and should take advantage of this.

Implement a batch download in favor of using a scroll from the client

In https://github.com/elastic/kibana/pull/13000 we moved the remaining use of the scroll API to a legacy endpoint. We should either add a query parameter to the Saved Objects find method to stream the entire contents, or create a new endpoint.

[snide]

Notes:

• Don't use tab structure for separating objects. List them all in one view, and just give a filter for that everything in one spot.
• Prolly don't need an export everything button if there are no tabs, just use the table header checkbox to select all, then hit export.
• Do we need the separated code blocks in the edit view? Why not just a large blob.
• When exporting objects that contain objects (say a dashboard with visualizations) right now it doesn't export the linked visualizations. Should we add a checkbox for this?
• Not for this, but it would be cool within monitoring to see performance of objects. What visualizations are slow?

[tylersmalley]

@tbragin - can you shed some light to why the edit object form exists and the role it currently provides? Dave and I assumed it was created due to limited editing capabilities in Dashboard, Visualize, and Discover but not sure if those reasons still exist.

[tbragin]

@tylersmalley It is meant as an advanced tool for examining and fixing object definitions. You are right that most of the times I've used it have been when something was not possible in another way. For instance, you might use it to update the index pattern or saved search on which a visualization is based, so you don't have to recreate it from scratch. Does that help?

[skearns64]

@epixa - when we built saved workspaces for Graph, I recall that you had originally requested that we not use the saved object infrastructure, because you felt like large parts of it would change - is this the change you were thinking about, or are there bigger changes in the works that we should be aware of?

@uboness - also on Graph, I believe you had requested that we not allow exporting of saved Graph Workspaces, so we did some work to exclude them from the Saved Object Editor, but I can't recall why. Are you comfortable with adding the ability to export all saved object types?

[uboness]

@skearns64 I believe it was because we actually didn't want to add any new functionality to this page at all. In fact we were planning to take all object CRUD operations out of the general settings page and instead have each app provide CRUD operations for its own objects... basically manage the objects where they belong (e.g. CRUD dashboards in the Dashboard app). Beyond that I can't think of any other reason for not adding it.. @markharwood do you recall something beyond that?

If we really need to keep the import/export feature, I'm fine for it to be under the management app... but for CRUD I still prefer to move it away from there.... in that respect, if we're going create dedicated forms for the different objects, I rather have that work be done within the design of the appropriate app.

[markharwood]

@markharwood do you recall something beyond that?

Original comments are here

As an end user I would personally value export/import of Graph saved objects - I think the concern you raised was possible overhead of maintaining BWC import parsing code. Maybe the general unease about the (lack of) security markings on any data saved in a Graph workspace was an added incentive to make exports hard too.

[epixa]

@skearns64 I think the bulk of those changes are done at this point, with the overhaul of the saved object apis and such. There are still some legacy aspects around UI componentization (or lack thereof), but I don't think those should stop us from embracing the infra if it makes sense.

[SamuelMV]

+1 We've started using Kibana 6 (from Kibana 4) and have to recreate all indexes and then change the visualizations, etc. When we used Grafana, we could import-export everything and it worked as a charm.

[elasticmachine]

Pinging @elastic/kibana-platform

[danielmotaleite]

We need a single spot to do config/dashboard/saved search/timelione/etc backups and restores. Either by recreating the cluster or by disaster recovery, having proper backup and restore calls are a must have. Right now its snake oil, kibana silently only exports part of the needed data.
So please, put some love on this feature