Warn how many objects or list objects affected when deleting a kibana object that is referenced by other objects such as an index pattern

[geekpete]

It might be useful to warn that x number of objects are referencing an object before deleting referenced kibana objects (mostly thinking of index patterns here but potentially searches, visualisations too?).
Perhaps even list the objects that are referencing the object targetted for deletion so decisions can be made before the delete is executed.
This is to avoid having a potential set of objects reference a non-existent object/pattern.

This is especially important for index patterns, since there's not yet any official process to change an index pattern for existing objects or repair existing objects that reference a non-existent index pattern as per: #3668

Though there is a way to manually fix such a situation where by manually editing the kibana object documents directly that reference the index pattern to use the new index pattern UUID or creating a new pattern object and overwritting the UUID field of the new pattern object document with the UUID value that existing objects still reference. A way to batch change this easily for a given set of objects might be super handy as indicated by the number of comments on the existing issue I mentioned.

v5.6.8 asks "Are you sure you want to remove this index pattern?"
v6.2.1 asks "Delete index pattern?"

at this point it'd be great to have a list of rammifications/what will be affected by this change, since the impact could potentially be large.

I do see the useful workaround for this scenario in 5.6.8 where a visualisation says an index pattern is missing do you want to recreate it, then offers to use the existing UUID for the newly created index pattern. This would help solve this issue once it's occurred, but thinking of a preventative feature here.

[chrisronline]

I love it. It feels related to #5947, #3127, #8804, and #16747 to some degree, but we definitely want to do a better job of surfacing and building tooling around these relationships.

[geekpete]

Yeah looks like it would definitely tie into those other ideas of surfacing relationships between objects, these are cool ideas for sure!

[geekpete]

@chrisronline Though all the referenced issues in your last comment are now closed, it seems in 7.11.1 we still don't warn of the full impact of deleting an object:

and

In a related context there was also the other issue of how you fix things once you have done a delete that breaks stuff, this issue was something that people were hoping for:
#17542

But was essentially replaced by Lens functionality that lets you pick index pattern from the dropdown.

Testing with deleting an index pattern that is referenced from a visualisation seems that you cannot even repair it now whereas a few versions back this seemed possible by selecting a replacement index pattern to update the visualisation with.
The behaviour now for Lens is to give up when loading a saved Lens visualisation and reset the visualisation options even if you select a replacement index pattern in the dropdown:

and the behaviour of aggregation visualisations, when you load a visualisation that points to a now non-existent index pattern:

when clicking the "re-create" link in the bottom right, you're sent across to the Saved Objects Management UI where you cannot create anything. This "re-create" functionality seems now disconnected from the repair step that it used let you do.

Tested on 7.11.1, but seems like a regression of functionality that used to work (repair objects by recreating index pattern that is now missing?)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

[elasticmachine]

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

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.