Remove saved object examples that promote accessing index patterns directly from the SO client

[stacey-gammon]

There are many places in our code base that access Index Patterns directly via the SO client and not through the Index Pattern Service. As it happens, many saved object examples show this, which could be proliferating the problem. We should remove these as examples and document this as an anti-pattern. If you don't own the saved object in question, you probably shouldn't be accessing it directly through the SO client, but rather through the owning plugin's API.

Related

• Clean up uses of accessing index pattern fields with "attributes.fields" #84352
• [Meta] Index Patterns Everywhere #90076

[elasticmachine]

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

[pgayvallet]

In #72028 (comment) we came to the conclusion that global HTTP apis for SOs was something we want to get rid of, in favor of per type specific endpoints.

Do you think that this assumption should also be true for the server-side SO apis, meaning that, overall, only the type owner should be allowed to interact with the type using the SO client/repository (and should expose proper service for other consumers to interact with the owner type if necessary)?

(Note: I'm excluding use cases such a centralized SO management, export, import, etc, from the question)

[stacey-gammon]

Do you think that this assumption should also be true for the server-side SO apis

Yes, I don't see why we would want to make an exception on the server-side. Whether it's REST APIs or plugin APIs, it seems access should be through the type owner's services and not the generic SOs services.

[pgayvallet]

Data views now have their dedicated service layer and APIs, and I think we adapted most example / doc accordingly - I'll consider this done and close the issue.