[Meta] Shareable saved objects for Analytics

[jportner]

Overview

In the 8.0 release, most consumers of saved objects undertook an effort to convert their isolated objects to become "share-capable": #100489

In the 8.2 release, data views (AKA index-pattern) are the first object type to be subsequently changed to be fully "shareable": #123991

Now we are ready for other consumers to start making their objects shareable as well (see Phase 2 of the Sharing Saved Objects Dev Guide for instructions). This must be done in a staggered approach, though -- any object type cannot be made shareable before all of its possible outbound references are also shareable. For example, you wouldn't want to share a dashboard if the visualizations it depends on can't be shared, too.

Here are the "reference graph" dependencies for Analytics saved object types, where a root cannot be made shareable until each potential leaf is also shareable:

Root	Leaf
lens, search, map, graph, query	index-pattern
visualization	search, index-pattern
dashboard, canvas-workpad	visualization, search, lens, map, index-pattern
canvas-element	-

Note for canvas-element: when you add a saved Canvas Element to a Canvas Workpad, it doesn't add a reference to that saved object, it just adds a copy of the Canvas Element's contents to your Canvas Workpad.

Therefore, I suggest that the Analytics saved object types should be made shareable in three phases:

1. lens, search, map, graph, query
2. visualization
3. dashboard, canvas-workpad, canvas-element

These could land in successive releases, or we could aim to make them land in one release, that's up to individual teams to decide.

Prerequisites

NOTE: One thing that the existing reusable UI components doesn't handle yet is reference/space synchronization.

Assume you have visualization "foo" that contains a reference to data view "bar", and they both exist in space "A".
A user may decide to share (or assign) the visualization to space "B", which includes the data view too.
Later, the user might decide to unassign the data view from space "B".
This means that the visualization is usable in space "A", but if you attempt to view it in space "B" it will appear to be broken (because the data view doesn't exist there).

Kibana doesn't attempt to enforce referential integrity*. You could delete the data view instead, and Kibana won't stop you, it will have the same result -- any visualization(s) that depend on the data view will be broken.

I'd suggest introducing a new element in the UIs for each of the root object types, so (in the aforementioned example) if you view the visualization in Space A, it will inform you that some of its references/relationships are "out of sync" and give you the option to fix it.

Alternatively, we could attempt to enforce referential integrity during the space assignment process and/or when users attempt to delete saved objects, but that could be much more technically complex.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[flash1293]

One related question - the LazyShareToSpaceFlyout will handle the case of assigning a whole tree of saved objects by a single action and make this transparent to the user, it's not something the app has to handle, right?

I'd suggest introducing a new element in the UIs for each of the root object types, so (in the aforementioned example) if you view the visualization in Space A, it will inform you that some of its references/relationships are "out of sync" and give you the option to fix it.

I agree with the general problem, however I'm not sure about the proposed solution - if the user is in space A, I don't think their mind is on fixing references in space B (they probably don't even know or care about space B), however if a user is looking at a broken dashboard in space B, then they definitely want to fix the problem otherwise they can't use it. What about doing it the other way around and if the user is trying to view the vis in space B, it's rendering the error state and prompting the user to re-assign the data view if the id was found in another space (given the user has access to both A and B). For users that only have access to space B and not space A we could adjust the error message for missing data views to include this case (something along the lines of "Was the data view unassigned from this space?")

Alternatively, we could attempt to enforce referential integrity during the space assignment process and/or when users attempt to delete saved objects, but that could be much more technically complex.

Slightly unrelated, but users deleting data views which are in use somewhere is a huge problem anyway so I think it's worth it to look into this topic holistically - maybe having a dedicated page for viewing and resolving missing references? I think it would be better to handle that in a single place instead of one-off solutions per app.

[jportner]

One related question - the LazyShareToSpaceFlyout will handle the case of assigning a whole tree of saved objects by a single action and make this transparent to the user, it's not something the app has to handle, right?

Correct!

I agree with the general problem, however I'm not sure about the proposed solution
...
For users that only have access to space B and not space A we could adjust the error message for missing data views to include this case (something along the lines of "Was the data view unassigned from this space?")

I like that idea. Perhaps the consumer could also search for that ID across all spaces (using the namespaces: ['*'] option), and if the object still exists in a space that the user has access to, we could show a button to fix it.
It might get tricky to do that for data views, though, since consumers rely on the data views API.

Slightly unrelated, but users deleting data views which are in use somewhere is a huge problem anyway so I think it's worth it to look into this topic holistically - maybe having a dedicated page for viewing and resolving missing references? I think it would be better to handle that in a single place instead of one-off solutions per app.

On one hand, that would be the easier thing to do. On the other hand, I think it adds friction and ultimately allows consumers to keep avoiding responsibility for broken references. (If a user tries to delete a data view that has inbound references, we should probably warn them about the consequences...)

In the case of changing an object's "assigned spaces" (e.g., "unsharing" an object from a space), it would add complexity to an already-complex UI, though.