[SAVED_OBJECTS] [AGGS] Step I to add aggregations in the find of saved objects

[XavierM]

Summary

This is a baby step to add aggregations in the find of saved objects, as we know find is a get, therefore, there is some limitation. I am hoping that I will be able to create a later PR to remove some limitations of this PR by having a post for find.

Anyway, the idea in this PR is that engineers who will need to add new aggregation types in src/core/server/saved_objects/service/lib/saved_object_aggs_types/*. I am using io-ts to validate the schema since io-ts allow recursive type and aggregations are recursive like the doc can show.

Dev Docs

SavedObjectsClient.find now supports aggregations, with the caveat that your field from the aggregation will have the attribute from your type saved object, it should look like this: savedObjectType.attributes.field. However, If you use a direct attribute of a saved object like updatedAt, you will have to define your filter like this: savedObjectType.updatedAt.

savedObjectsClient.find({
      type: 'savedObjectType',
      sortField: '@timestamp',
      sortOrder: 'desc',
      search: '',
      searchFields:'',
      fields: ['id', 'name', '@created', '@timestamp'],
      aggs: '{"aggName":{"aggType":{"field":"savedObjectType.attributes.field"}}}',
    });

Checklist

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

Some architectural questions:

[rudolf]

I think the io-ts types are "scalable" enough to be able to construct a whitelist for excluding aggregation scripts.

However, we need a scalable solution to prevent aggregations on invalid fields (fields from other saved object types). So I think the next step should be to add the adjacency matrix bucket aggregation and find a way to prevent invalid aggregation fields that wouldn't result in a lot of complexity once we cover the entire aggregation API surface. We can use the alternative aggregation syntax #64002 (comment)

[rudolf]

Along with the feedback in #64137 I'm happy with this approach 👍

[rudolf]

Left some initial comments but will take a deeper look later

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: cb7ada3

Metrics [docs]

Distributable file count

id	before	after	diff
default	43025	43030	+5
oss	22550	22753	+203

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	547.9KB	548.0KB	+93.0B

History

• 💚 Build #89498 succeeded 462d87e
• 💔 Build #87531 failed 2dc3ff8
• 💔 Build #87459 failed 48dcdda
• 💔 Build #87453 failed 2fb9a2c
• 💔 Build #87389 failed 4f667d4

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[pgayvallet]

We are getting very close! Got a few questions (most significant one being #64002 (comment)) and some NITs:

[pgayvallet]

NIT: slightly misleading message. I would rather have something like cannot perform aggregation on dashboard type as it was not included in the search or something if possible.

[LeeDr]

Since we're past 7.11.0 FF, and this isn't a bug fix, should probably bump to 7.12.0.

[pgayvallet]

Thanks @XavierM for this amazing work. I took the liberty to fork your PR to finish the last remaining bits.

Closing in favor of #96292