[ML] Transforms: Filter aggregation support

[darnautov]

Summary

Resolves #60015. Adds support for the filter aggregations:

The following filter aggs are presented:

• term
• number range
• exists
• bool

All the other filter aggs use the plain code editor for now.

Please pay attention to filter aggs field support mapping, this dictionary has to be completed. I haven't found the documentation for kibana field types I can look up to resolve it.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility, including a check against IE11

[qn895]

I think we can disable the Apply button if one of the input is valid. Instead of applying the previous selection.

[darnautov]

A minor suggestion is with the bool it can be hard to write out the conditions in that small space. Perhaps this can be done in a follow up PR.

Also since this is for Kibana users I think having a link to the documentation for query & filter might be useful here. If I'm using this the first time without knowing about elasticsearch, it would be hard to understand what I need to do.

hey @qn895 , we considered changing the design (I did a demo during the weekly meeting), but it's out of scope for this PR. Regarding the link to the documentation - we don't have to cover all cases, and I presume the users who deal with transforms are pretty advanced with ES 🙂

[darnautov]

I think we can disable the Apply button if one of the input is valid. Instead of applying the previous selection.

@qn895 we should not disable the button, because the user might expect some new value which is not presented in the dataset yet. I will remove the red underline that comes from the combobox control

[darnautov]

@qn895 Just pushed some enhancements for the term selector 66308fa to allow custom options

[darnautov]

Found the following error when trying to switch to and from the JSON editor when editing a range filter agg:

thanks for spotting it @peteharverson , just pushed the fix 57b75c4

[qn895]

Tested and LGTM

[darnautov]

@elasticmachine merge upstream

[pheyos]

Functional test changes LGTM, just left a data-test-subj naming suggestion, but feel free to merge without it.

[walterra]

So far we followed the principle that each option available in the groupby/agg-dropdown adds a valid configuration with reasonable defaults without a requirement to edit some form. This was a deliberate choice to allow users to quickly add different aggs by just using the keyboard (search in the dropdown, hit enter, search again, hit enter ...).

Can we try to achieve something similar with filter? For example, what if we offer an option for each agg within the dropdown so we can add a valid default config right away? Something like this:

Another thing is that for items with additional configuration options we try to provide a summary or hint at the custom settings, for example the interval for histogram or date_histogram group-by configuration. We should aim for something similar with filter aggs, otherwise there's no way of knowing about the settings without opening the edit-popover. For example:

[darnautov]

So far we followed the principle that each option available in the groupby/agg-dropdown adds a valid configuration with reasonable defaults without a requirement to edit some form. This was a deliberate choice to allow users to quickly add different aggs by just using the keyboard (search in the dropdown, hit enter, search again, hit enter ...).

Can we try to achieve something similar with filter? For example, what if we offer an option for each agg within the dropdown so we can add a valid default config right away? Something like this:

Another thing is that for items with additional configuration options we try to provide a summary or hint at the custom settings, for example the interval for histogram or date_histogram group-by configuration. We should aim for something similar with filter aggs, otherwise there's no way of knowing about the settings without opening the edit-popover. For example:

@walterra I believe it is not possible to achieve such behavior with filter agg. There are so many different variations and configs, so we can't predict what will be suitable for the user. Even the basic setup with term agg requires a value and we can't just add any value from the data set.

Regarding naming - @peteharverson proposed to have term value as an agg name, and I think it's quite a good idea because it clearly indicates the filed in result index. Maybe it could be something like value.count, not sure

[walterra]

I tested the terms filter and this looks good as you described. I was referring to number based filters like range though, maybe we can add the range to the item summary like the histogram interval information.

[walterra]

Code LGTM, great work with how we can now compose forms!

[darnautov]

@walterra just pushed 7cf1833 support for helper text in the aggregation list. How it looks for the filter range

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 7cf1833

History

• 💚 Build #51679 succeeded e2ce842
• 💚 Build #51490 succeeded 67a85e1
• 💚 Build #51463 succeeded 57b75c4
• 💔 Build #51444 failed 66308fa
• 💚 Build #51401 succeeded 69ee8ae

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

[peteharverson]

Tested latest edits and LGTM!