Better UX if user tries to delete hidden saved objects

[bhavyarm]

Kibana version: 7.14.0 BC4

Elasticsearch version: 7.14.0 BC4

Server OS version: darwin_x86_64

Browser version: Chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from staging

Describe the bug: If the user tries to delete hidden saved objects ( in 7.14.0 - rules and connectors) - Kibana UI shows the generic delete dialogue with a table list with the "Delete" button activated. But if you click on it - obviously nothing happens.

Can we please display this better? We tell the user the selected objects cannot be deleted (not sure if we can tell them they are hidden?) and that's all?

[elasticmachine]

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

[thesmallestduck]

Providing some context: Hidden Saved Objects are saved objects that generally we want users to ignore. They may get managed by other saved objects or processes that users can interact with in other ways. However a common pattern we see, for example when upgrading between majors, is to export all the saved objects from one cluster and then to import them all into a new cluster. So we've decided to expose hidden saved objects to the user for the sake of this export functionality. However it means that operations like bulk delete now become more complex, since there are saved objects in the UI that can be deleted and saved objects that can not. This has left the delete UI feeling a little silly at times.

@ryankeairns I wanted to see if you had any thoughts about this (or someone else from the design team). The simplest change would probably be to include a list of selected objects that cannot be deleted alongside the list of selected objects that can be deleted in the modal. It also might be worth exploring exposing the "hidden" property of a saved object in the table, perhaps with a lock icon and a mouse-over explaining the "restricted" nature of the saved object. These are just thoughts, the general problem is communicating to the user the restricted nature of some saved objects, and then gracefully handling this restriction in deletion UI.

[ryankeairns]

+1 to the idea of denoting this in the table. With regards to selection and modal... can any bulk actions (delete aside) be taken on hidden objects? or can we essentially block all 'hidden items' from bulk actions?

If it's the latter, then we could just prevent those rows from being selected as seen in this EUI docs example:
https://elastic.github.io/eui/#/tabular-content/tables#adding-selection-to-a-table

If you can still, say, export the hidden items, then we may need to explore the modal ideas you've suggested.

[pgayvallet]

can any bulk actions (delete aside) be taken on hidden objects? or can we essentially block all 'hidden items' from bulk actions?

Yea, they can also be selected for export, and are exportable. UI improvements will have to be done in the modal.

I guess we'll have to display the non-deletable object in the modal's list and add a visual indication that they can't be delete, in addition of a warning on top (which we already have, just need to rephrase)

@ryankeairns any insight on what the best way to show in the table that some items can't be deleted?

[ryankeairns]

can any bulk actions (delete aside) be taken on hidden objects? or can we essentially block all 'hidden items' from bulk actions?

Yea, they can also be selected for export, and are exportable. UI improvements will have to be done in the modal.

I guess we'll have to display the non-deletable object in the modal's list and add a visual indication that they can't be delete, in addition of a warning on top (which we already have, just need to rephrase)

@ryankeairns any insight on what the best way to show in the table that some items can't be deleted?

I looked through the existing EUI table props and nothing jumps out as me. I would recommend adding the number of hidden items/items that cannot be deleted in the callout (on the modal) when you rephrase it. Something like "23 objects are hidden and cannot be deleted...." and just don't include in the table within the modal.

On the original, underlying table we should have some sort of indicator (column or badge near title) indicating hidden fields. This would allow users to reconcile "I checked 40, but only 17 can be deleted because 23 were hidden". If possible (now or in the future), a filter for 'hidden' would also be beneficial.

[pgayvallet]

I would recommend adding the number of hidden items/items that cannot be deleted in the callout (on the modal) when you rephrase it. Something like "23 objects are hidden and cannot be deleted...." and just don't include in the table within the modal.

That's very close to the current behavior. Should the only modification be to rephrase the warning to include the number of objects that won't be deleted then?

a filter for 'hidden' would also be beneficial

May make sense, but as the hidden info is type-based and not object-based (all the objects of a given type are, or not, hidden), this kinda goes in conflict with the current 'type' filter/selector, so it may leads to user confusion too.

[ryankeairns]

I would recommend adding the number of hidden items/items that cannot be deleted in the callout (on the modal) when you rephrase it. Something like "23 objects are hidden and cannot be deleted...." and just don't include in the table within the modal.

That's very close to the current behavior. Should the only modification be to rephrase the warning to include the number of objects that won't be deleted then?

Correct. Short of more involved UI changes, this feels like a minimal approach.