Currently none of the above visualizations listen for KQL/Kuery queries, if that feature is enabled.
The reason for this is the usage of the broken dashboard_context for generating the DSL for a query. This plainly ignores if the query is actually written in KQL/Kquery.
This class should be removed completely and rather the correct way of implementing this should be used:
The request handler of a visualization will get passed in the filters and query in the params object (2nd argument to the request handler). Every visualization should use that query and filters instead of trying to access any global state (like dashboard_context does). Accessing global state in any visualization will break other features that we are planning like Custom time ranges per dashboard panel (#17776). It's an anti pattern that makes the whole architecture unstable and hard to maintain.
A visualization needs to look into filters/queries passed to it's request handler. To compile the query, there are APIs for Lucene and Kuery. We should imho look into creating one central "Query API" (cc @elastic/kibana-discovery), that accepts any query object and that itself will check what query type that query is and use the appropriate compiler. That way we don't duplicate that work into each individual visualization.
That compiled DSL needs then to be merged into the query done by the appropriate visualization. Since KQL/Kuery needs to be compiled against an index pattern, all visualizations need to figure out the appropriate index pattern, for their given index pattern string (maybe we could move that into the Query compile API?).
Currently none of the above visualizations listen for KQL/Kuery queries, if that feature is enabled.
The reason for this is the usage of the broken dashboard_context for generating the DSL for a query. This plainly ignores if the query is actually written in KQL/Kquery.
This class should be removed completely and rather the correct way of implementing this should be used:
The request handler of a visualization will get passed in the
filtersandqueryin the params object (2nd argument to the request handler). Every visualization should use thatqueryandfiltersinstead of trying to access any global state (likedashboard_contextdoes). Accessing global state in any visualization will break other features that we are planning like Custom time ranges per dashboard panel (#17776). It's an anti pattern that makes the whole architecture unstable and hard to maintain.A visualization needs to look into filters/queries passed to it's request handler. To compile the query, there are APIs for Lucene and Kuery. We should imho look into creating one central "Query API" (cc @elastic/kibana-discovery), that accepts any query object and that itself will check what query type that query is and use the appropriate compiler. That way we don't duplicate that work into each individual visualization.
That compiled DSL needs then to be merged into the query done by the appropriate visualization. Since KQL/Kuery needs to be compiled against an index pattern, all visualizations need to figure out the appropriate index pattern, for their given index pattern string (maybe we could move that into the Query compile API?).