-
Notifications
You must be signed in to change notification settings - Fork 25.8k
More flexible script query #21479
Copy link
Copy link
Closed
Labels
:Core/Infra/ScriptingScripting abstractions, Painless, and MustacheScripting abstractions, Painless, and Mustache:Search/SearchSearch-related issues that do not fall into other categoriesSearch-related issues that do not fall into other categories>enhancement
Metadata
Metadata
Assignees
Labels
:Core/Infra/ScriptingScripting abstractions, Painless, and MustacheScripting abstractions, Painless, and Mustache:Search/SearchSearch-related issues that do not fall into other categoriesSearch-related issues that do not fall into other categories>enhancement
Type
Fields
Give feedbackNo fields configured for issues without a type.
Now that Kibana supports painless, some strange things have come up around filtering. This is a proposal to implement a thing in Elasticsearch so Kibana doesn't have to do upsetting textual manipulation to user generated script fields.
Background: Kibana lets users configure script fields once and reuse them. The specific usage that is troubling is filtering which Kibana implements by creating a query like this:
Specifically, the
($scriptText) == params.valuepart is scary because script fields that are perfectly valid painless most places are not valid in this script context. Scripts that containreturn,;, or variable declarations are in trouble with a construct like this.I propose a new version of the script query that'd look like this:
Instead of casting the return of the script to a boolean we cast it to whatever type is sent in the
matchesfield and then check for equality.