Sharing saved-objects: phase 1.5

[jportner]

Phase 1.5 from #27004.

Overview

This will support import/export for "shareable" types without references. It will also support existing operations in the Saved Objects Management Screen (server side and client side) and add a UI for sharing a saved object to other space(s).

Client-side changes

All changes are in the Saved Objects Management screen.

• Update table: add "Shared spaces" column, labels for known/unknown spaces, tooltip
• Update actions: add "Share to space" option (for multi-namespace types) and rename "Copy to space" option
• Update delete confirmation modal: add "This/these is/are shared in X spaces" banner, change "Delete" button to "Remove from space" (primary) and "Delete everywhere" (secondary) (deferred until Phase 3)
• New flyout for "Share to space"
• Update toasts

Server-side changes

• Update export for multi-namespace types: strip namespaces
• Update import for multi-namespace types: regenerate IDs
• Update copy_to_space for multi-namespace types: ??? (should be no changes required, as this relies on export and import)
• New bulkRemoveNamespaces operation for SavedObjectsClient edit: don't need this after all, the current multi-delete functionality in the Saved Objects Management screen uses separate delete operations for each saved object, we will just use separate removeNamespaces operations for each multi-namespace saved object instead.

Other

• Produce benchmarks for imports before and after changes
• Update integration tests
• Update functional tests

[elasticmachine]

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

[jportner]

Note: a large portion of this issue will require changes to the Saved Object Management screen, which is currently in the legacy platform and is being moved into a separate plugin in #50308.

[arisonl]

@jportner @legrego An attempt to summarise our recent discussions around copying saved objects in view of the introduction of the ability to share follows (mainly the problem space, the alternatives and the user/UX considerations that we have discussed):

1. Context: Currently a saved object lives in one space. We are working on adding the ability to share a saved object in multiple spaces, i.e. access it and/or change it from more than one spaces.

2. The current ID of a saved object contains a prefix that signifies its space, e.g.: space1:objectA. To implement shared objects without introducing breaking changes to current user workflows, we need to both remove the space ID prefix (since objects can now live in multiple spaces), but at the same time introduce a link to the origin of an object, if that object happens to be a copy. Why:

3. This is because a copy operation in Kibana is currently actually a pseudo-copy: If you copy objectA from space1 to space2, change it in space2 and then copy it back to space1, Kibana will ask you to either skip or overwrite space1:objectA, despite space2:objectA potentially being a completely different object from a user perspective, due to edits that have happened to it in the meantime in space2. Users have used this mechanism to manually sync objects across spaces. To retain this behaviour (pseudo-copy) and avoid breaking changes with the introduction of shared objects, we are changing the object ID convention by removing the prefix and introducing a reference to the original object (in order to resolve such conflicts).

4. From a user perspective though, with the introduction of shared objects we will have a real syncing mechanism: If you want to sync an object across two spaces, simply share it and it gets synced automatically. Hence the manual sync discussed previously becomes obsolete and users would not expect a conflict that forces them to skip or overwrite as in point-3 previously. Instead, they would expect a real copy and they might not even be aware (or care at all) that the two objects have the same origin. (Some of the scenarios are described here in more detail from a user perspective: https://docs.google.com/document/d/1-A2f2fM0L0FuF8RmKmcVSOPPvlp3Pjdw0qEPzrvhxi0/edit)

5. I believe that we are in consensus that point-4 previously is the right approach and we are looking to make this behaviour the default one (and possibly keep the current one as an option for a transitional period) in 8.0.

6. For 7.x, we have three options

   • Retain the current pseudo-copy behaviour only. Medium effort.
   • Retain the current pseudo-copy behaviour as a default and add the ability of a true copy (i.e. introduce the behaviour in step-4) as an option. Then in 8.0, reverse the default to the expected real copy behaviour. Highest effort.
   • Introduce a breaking change by removing the pseudo-copy behaviour and introducing real copies. Lowest effort but probably not a real option.

If this is a fairly accurate summary, we will need to put that extra effort required to introduce true copies sooner or later, hence does option 6b above feels attractive, despite the cost?

cc @alexfrancoeur @jinmu03 @kobelb @mdefazio

[jportner]

If this is a fairly accurate summary, we will need to put that extra effort required to introduce true copies sooner or later, hence does option 6b above feels attractive, despite the cost?

Well put! I agree.

Just wanted to note that this does not mention imports, which effectively behave the same way today. I assume your intent is to make the same changes to imports, yes?

[arisonl]

Correct!

[arisonl]

If there are no objections then, let's move to this direction. Let's draft the UX with @mdefazio and validate with the rest of product as we move forward // cc: @jinmu03