"Delete" and "Copy to Space" returns errors for hidden saved object types in Saved Object Management Page

[ymao1]

For this issue, the alerting team would like to make the hidden saved object types action and alert importable/exportable. Setting importableAndExportable: true makes them show up in the Saved Object Management page and allows use to import and export. However, the "Delete" and "Copy to Space" buttons are also enabled for these types.

Clicking "Delete" gives a 404 Not Found error and a loading screen that doesn't go away.
Clicking "Copy to Space" gives a 500 internal server error.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[Bamieh]

Just to clarify delete and copy to space are expected to work or to be hidden from the UI?

I'm assuming we should not show them since this flag only enables exporting/importing them correct? CC @pgayvallet

[ymao1]

I would expect it to be disabled or hidden for hidden saved object types.

[pgayvallet]

Just to clarify delete and copy to space are expected to work or to be hidden from the UI?

That's a good question. We're probably good just hiding the actions from the UI, as least short time to address the issue.

Now, functionally having the ability to delete hidden SOs from SOM may make sense, now that we are displaying them anyway. It would require to use our own /som/delete API/route, but that would be consistent which what we are planning long term for SOs by removing the global/generic SO routes anyway.

Not sure about copy to space though. @elastic/kibana-security wdyt? Should we, ideally, allow copy to space for hidden types that are now 'manageable' from the SO management page?

[legrego]

Not sure about copy to space though. @elastic/kibana-security wdyt? Should we, ideally, allow copy to space for hidden types that are now 'manageable' from the SO management page?

Ideally I think we should enable this, but realistically I think we should hide the actions for the time being.

Copy-to-space uses import/export behind the scenes, and I'm not sure what this experience should look like with the introduction of import/export hooks. IMO we should disable this functionality until we have a better understanding of how these hidden types behave under import/export, and whether we want that same behavior for copy-to-space. It's possible that we'll want to change the behavior when performing a copy. Disabling this functionality now will give us some time to investigate a proper UX for these object types.

[pgayvallet]

I'm currently working on that one, to hide/disable the unsupported actions.

If disabling the copy to space and share to space actions, and hiding the delete button on the inspect page is quite straightforward, I'm a bit stuck on the batch delete action.

Atm users can select multiple objects in the table, and then click delete to perform a bulk delete operation. I'm not sure what the best way to handle the case when a mix of hidden and non-hidden types are selected.

A few options:

• disable the button (in the main UI, not the modal) as long as there is at least one hidden object selected (not sure how to display an info/warning about the reason in that case)
• disable the button in the modal as long as there is at least one hidden object selected, with a warning stating that some objects cannot be deleted
• only display the deletable objects in the modal, with the same warning
• do not inform the user, and silently remove the hidden objects when performing the delete request to the server
• ??? what else

disable the button in the modal as long as there is at least one hidden object selected, with a warning stating that some objects cannot be deleted

seems like the best compromise between implementation cost and user experience, but wdyt?

[ymao1]

only display the deletable objects in the modal, with the same warning

I like this option vs disabling the button, unless we are offering the ability to somehow enable the button on the modal via some action? Otherwise, the user would have to close the modal and figure out on her own which ones can and can't be deleted. Maybe the warning could just tell them that some of the selected objects are not deletable and then clicking the "Delete" button will just delete the deletable ones?

[pgayvallet]

Maybe the warning could just tell them that some of the selected objects are not deletable and then clicking the "Delete" button will just delete the deletable ones?

After discussing it with my 'personal UX guy', seems like this is the expected UX behavior. Will do that then