Summary

When we first added the ability to find saved objects across spaces, we made the decision to treat the wildcard (*) namespace as the default namespace from the repository's perspective. In other words, if a * ever made its way to the repository, we would treat this the same as the default namespace.

For the default distribution, this wouldn't ever happen organically. For the OSS distribution, this would happen for API consumers who explicitly specified the namespaces=* query parameter.

See #67644 (comment) for context around this decision.

This PR changes the behavior of the wildcard, and instead treats this as a true "search across all namespaces". We're making this change in order to support space-aware Machine Learning jobs (#82639). ML has two use cases for this functionality:

Initialization

When Kibana starts up, it needs to know if any ML job saved objects exist. If not, ML performs an initialization process whereby it creates a saved object for each job that exists in ES.

The initially proposed approach relied on querying the kibana index directly, which is undesirable.

With these changes, ML can instead use an instance of the Saved Objects Repository to search for objects across all spaces:

await savedObjectsRepository.find({
  type: 'ml-job',
  namespaces: ['*']
});

Repair

The ml-job saved objects are merely proxies to the actual job stored in ES. Given this "linked" nature, it's possible for Kibana's representation of available jobs to differ from the actual set of available jobs. The ML Management screen will provide a way to repair this in order to keep the two in sync.

In order to effectively repair Kibana's representation of ML Jobs, we need to be able to search across all spaces in order to see if a specific ML job exists within Kibana anywhere.

cc @jgowdyelastic