I created Tag field including fields called “CVEId” which contains values like ‘CVE-yyyy-xxxxxx’ like ‘CVE-2019-0211’.
I created lookup that uses field “CVEId” as value.
I was expecting …
Tag input field would show all tags because the keys are equal to value.
Instead I’ve got …
Entry is unavailable message in tag field because it searches value in lower case (‘cve-yyyy-xxxxx’) instead of original case (‘CVE-yyyy-xxxx’). I believe the values should be compared in original case.
Workaround
I created function that calculates lower case value from “CVEId”
I set up lookup to use Value Method the result of function “CVEIdLowerCase”.
Then it works.
I don’t think we have a function that converts the searched string to lower case. Also if the database is set up case insensitive (which it is by default) it should not matter anyway?
Well, I use Postgres database which is case sensitive, so that’s why it matters. I examined little bit further and the transformation of case happens somewhere in the client.
It receives data with capital letters in the method /internalApi/UIService/GetData
But when sending these data into method /internalApi/UIService/GetLookupLabelsEx, it sends them in lower case.
As I quickly checked the client, there is multiple use of ‘toLowerCase’ method among classes so there is probably some transformation. I can now live with it because it needs only change of filtering method on lookup to use lower case column, but it is something unexpected and inconsistent.
Well, I can imagine that client can use lower case comparisons, but I would expect it would sends data into other methods as it has received it.
@jsusen do you have any idea if and why would this happen? Maybe someone was not happy with guids in upper case and converted them to lower, but that does not matter and ruins the string ids. In such case it would be a bug.
The only reason I can imagine would be if guids would come upper case from SQL Server and for some reason we would find it useful to convert them lower case. But as they come lower case from .net this should be no issue. So I think we should stop converting the input and see if it breaks something.
