Saved object management - add plugin contract functionality for displaying SO relationships in other management screens

[mattkime]

This topic is drawn from #132385 - displaying SO relationships in data view management

There are two questions data view management would like to answer for users - Are there any saved objects using a particular data view? Which saved objects depend upon a given data view? These questions are important when considering the impact of data view changes and removal.

I assume there are other saved objects which have a similar relationship to other saved objects although I'm not sure what they are. Data views are uniquely central to kibana.

While this information is available in saved object management, its not where people go when managing data views. The info is much more useful in the correct context.

Much of the behavior between the general SO relationship viewer and the data view specific version is basically identical therefore some shared code is expected -

APIs (on plugin contract)

• getAllowedTypes
• getRelationships

Functions (via import)

• getSavedObjectLabel
• getDefaultTitle

Types

• SavedObjectManagementTypeInfo

---

There are a number of ways this problem could be solved. I'm aiming for something that is relatively quick and simple rather than aiming for an ideal implementation. We could reevaluate later if more specific instances of relationship display are created.

[elasticmachine]

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

[pgayvallet]

Use some of the currently internal SOM features by exposing them from the SOM plugin contract

No objection, glad to allow the SO management APIs to be used elsewhere.

exporting some static utility functions

I have no problem exposing utils such as getSavedObjectLabel, but with the global package architecture coming, we should ihmo avoid exposing static exports and always using plugin contracts instead (or create a package, but that probably don't make much sense here). Would it be fine if those utils were exposed from the contract instead, as for the APIs listed previously?

types

All types used by the exposed contract will for sure be exported too.

BTW, you're planning on re-implementing the UI components used to display the relationships on your page? It's not the best in term of re-usability, but realistically given the state of the code of the SOM UI components, that's the quickest and easiest for sure.

[mattkime]

Would it be fine if those utils were exposed from the contract instead

👍

BTW, you're planning on re-implementing the UI components used to display the relationships on your page? It's not the best in term of re-usability, but realistically given the state of the code of the SOM UI components, that's the quickest and easiest for sure.

Yeah, right now quick and easy works for me. I could see some sort of shared component being created for this but we could do that later if we see the need.

[mattkime]

Closing this as it was implemented as part of #132385