You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ES|QL] Use correct timeFieldName for time brush filter (elastic#221322)
## Summary
fixelastic#221241
## Bug and fix descriptions
The logic that applies a time filter by updating the time picker vs
adding it as a filter pill in the filter bar is described here:
https://github.com/elastic/kibana/blob/e877bafa3e4725d3e7cfd3b2ca0be4bc6d88a0b9/src/platform/plugins/shared/unified_search/public/actions/apply_filter_action/apply_filter_action.tsx#L107-L114
The `extractTimeFilter` function extracts the `timeRangeFilter` only if
the `timeFieldName === keys(filter.query.range)[0]` . The problem was
that the first key of `query.range` was different than the
`timeFieldName`. That `timeFieldName` in the ESQL world was wrongly
applied via the ` table.columns[xAxisColumnIndex].name` that doesn't
reflect the actual column name for ES|QL, in fact that name reflect the
visualization label name for the time dimension. In particular, before
the fix, that timeFieldName was set as the axis name (e.g.`@timestamp
every 5 minute` ) and cause the time range filter to fail to be
extracted from the filters list.
A combination of two PRs caused this to be now anymore the correct
behaviour:
- this PR elastic#196049 introduced the
use of the `souceField` as field name for the creation of filter from a
range
- this PR elastic#217719 instead
introduced the use of `sourceField` also for ESQL datasources. This
field points to the actual column name described in the ESQL query.
Both PR causes the `extractTimeFilter` to fail to extract the
timeFilter, pushing the filter up to the filter pills.
### Side notes
This could be probably fixed in other ways, like by avoiding using the
`sourceField` in ESQL, or by using only the column.name in the filter
creation, or by avoiding checking the `timeFieldName` against the
`query.range` key (not really sure why this is required). In general the
problem here is that there is a low confidence on what these
fields/params are supposed to be and which is supposted to be the
identifiers to use everywhere. For example the column ids reflects only
a link between the rows and the column descriptions, the name is the
associated label, but can we rely on that label for filtering? i believe
we need a stronger connection with the data and the actual original
source field or column identifier is a better choice.
I believe a valid subsequent task is
elastic#189044
(cherry picked from commit eb4ba96)
0 commit comments