[KQL] field name case insensitivity

[ghudgins]

Describe the feature:
Consider allowing KQL queries to return fields matching any casing in the field name.

Example: Data contains AFieldToSearch:value. User enters afieldtosearch:valueand returns results despite not entering the exact field name correctly.

If there is a valid case for keeping today's case-sensitive field behavior, consider making this a configuration.

Describe a specific use case for the feature:

The problem today:

• A field exists AFieldToSearch.
• A user comes to Discover to search a field. In the KQL query the user enters afieldtosearch without noticing the autocomplete.
  • Alternatively, a user could miss the autocomplete entirely if they paste in an incorrect cased version of the field name from a data dictionary / wiki / email.
• The user submits the search which comes back empty. The user gives up or requests support from an administrator.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[lukasolson]

While it may seem like a more user-friendly experience to make field names case-insensitive, it is also possible to have multiple fields within an index that are the same except with regards to case. For example, you can create this document in ES:

POST tmp/_doc
{
  "foo": "bar",
  "FOO": "baz"
}

In this scenario, if a user were to query foo: bar, would we internally translate it to foo: bar or FOO: bar?

[ghudgins]

In this scenario, if a user were to query foo: bar, would we internally translate it to foo: bar or FOO: bar

Yes, I believe so. Search all fields that match foo with all values that match bar. Maybe we could offer the user the ability to choose if it's case sensitive (via the ") but I think more people would have successful searches if the default / autocomplete was the insensitive search.

Same problem exists on the value side too... ("foo":"Bar" doesn't return bar documents)

We can, of course, wait until we evaluate search syntax more holistically for KQL but this felt low hanging! I also ran into a bunch of case sensitivity problems in a recent usability study (can link you if you're interested...part of the problem was the question/prompt pointed users right at it but many of the participants struggled)

CC @cchaos

[cchaos]

Yes! Case-insensitive by default, only if wrapped in quotes is it case sensitive. But what do we do about exact/full match versus partial? For instance, we want to search for Bar but want to see results as Bar and Bar food but not bar manager.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[lukasolson]

Related: #70724

Maybe we can at least highlight in-line when a user has typed the field name incorrectly ("Field myfield does not exist. Did you mean MyField?")

[kertal]

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.