Really? Not sure I agree...

@chrisjstevo You mean

1. should be case insensitive but not always be lowercase or

2. actually should be case sensitive but when user types into the filter box, it gives suggestions (not case sensitive) but values suggested are the case sensitive?
   i.e. user types aa --> it suggests AAPL.L ? so going into server is still AAPL.L?

Really? Not sure I agree...

@chrisjstevo why do you think case matters?

if user wants to search for, say "london" and uses a startsWith, and they get no results, because the description happens to start "London" or they get back only some of the results because the casing is not consistent in the data, doesn't feel to me like we're doing them any favours.

The code for the filter for inmemory table found
https://github.com/finos/vuu/blob/main/vuu/src/main/scala/org/finos/vuu/core/filter/FilterClause.scala

Need to address this in the StartWith typehaead function.
Code found in InMemColumnValueProvider for in-memory table
Also need to review for virtualized table

Do we need to make the string filter functions also case insensitive? i.e. contains, equal, in

Wendy will be working on this

To summarize, following need to be reviewed in typeahead & string based filter (equal, in, contains, starts, end, not equal) functionality

• We have agreed type ahead should be case in-sensitive as users may not know the exact casing of the text they are looking for.

• For filters, there are valid cases where you may need the match on exact case & valid case you want it to match regardless of the case. E.g. If you are looking for GB vs Gb in size has different meaning.

• Another consideration is how the type ahead work together with the filters. If type ahead is case-in sensitive, the search for "london" will return "London" and "london". Filter is applied on the entered value of "london" and if that is case-sensitive, results will only return "london" which may not be what user expected based on the typeahead results.

Proposal

We need to support both case in-sensitive & case sensitive use cases.
Most "Find" tools has a "Match Case" toggle.
If we want the type ahead and filter to be in sync, this toggle need to apply to both when on/off

If we make typeahead only case insensitive (and not the actual filtering) the problematic use cases are starts and contains filters.

In these cases, the user is entering the filter pattern that will actually be sent to the server. In the case of a simple = filter, the pattern entered by the user is just a prelude to picking the actual value to be submitted from the typeahead list. The value submitted to the server will come from the list, so case will always be correct.

In the case (pun intended) of a starts filter, the list just shows user examples of the values that would match if they submitted this pattern. They cannot select from this list (the list items are rendered greyed out and do not support selection)
Selecting a specific item from the list would defeat the purpose of the starts operator . In this case, if the starts operator is applied as a filter that returns case-sensitive results , the results might not match what the typeahead showed.