[BUG]Control visualization case sensitivity versus Dynamic dropdowns

[shivshankarb]

While using control visualization for the options list, it appears that searches are case sensitive.

However if we disable the dynamic option searches aren't case sensitive

So its Dynamically Changing Lists vs Case Insensitivity/Longer Lists we can't choose both.

[kavilla]

[Triage]

@joshuarrrr could add this to your queue to research if you have availability. If this is expected it should be more explicitly called out. @KrooshalUX we should see if this even makes sense as an end-user experience.

[KrooshalUX]

Tagging @btzeng for visibility

[AMoo-Miki]

As an end-user, I do not expect a type-ahead or search field imposing case-sensitivity; this is bad UX.

[joshuarrrr]

@AMoo-Miki The problem here is that, by default, the query to OpenSearch to get the typeahead values are themselves case sensitive. While we can refactor that, I think it would be nice for the user to have the option of specifying whether they want case sensitivity or not. For example, in VSCode, I usually have my search set to be case insensitive, but appreciate having the toggle when I'm trying to further narrow the results (of types vs methods, for instance).

[joshuarrrr]

See also https://github.com/opensearch-project/OpenSearch-Dashboards/issues/576 and https://github.com/opensearch-project/OpenSearch-Dashboards/issues/3428 for a broader perspective of our inconsistent handling of case.