Metadata custom list included “Vanessa” (one of a list of names setup to be selected from drop down)
Project search for “vanessa” - hits Vanessa in that drop-down list as selected
Proved by selecting a different name from the list and refreshing the search… document hit disappeared AND by the fact that the search was limited to the named metadata field (“Point of View”) in the project search list (All, Text, Title…)
To reproduce… create such a list, constrain the project search, do a case sensitive search.
I am able to reproduce this with a custom metadata field of type List. Project Search does ignore the Case Sensitive setting with fields of type List. (It worked correctly with a field of type Text.)
You would only care if ‘Vanessa’ and ‘vanessa’ were both list items. But since you’re defining the metadata you can simply choose not to do that.
And on the flip side, do you want the 20 documents with ‘Vanessa’ metadata to disappear from your search because you forgot to hit the shift key and searched for ‘vanessa’ instead?
Thanks, this has been filed—looks like just an oversight; as @JimRac said, case sensitivity is working with the text-type custom metadata, and it’s working properly with status and labels. For now, if you need to distinguish between the two values, your best option is probably doing as @kewms suggested and tweaking the custom list metadata to make the values unique in some way other than capitalisation.
On principle, things should work as described, but more importantly I was looking for miscapitalisation. My default search is All because 99% of the time it’s obvious where the hit is: it can be seen instantly (lack of highlighting elsewhere, or other indication of hit location has been raised previously).
On this occasion I just couldn’t find the hit and, since there were few in docs with long text, synopses, long notes etc. it was hard to say I wasn’t failing to see it. Of course, I then narrowed down by search scope and was baffled by the results, but all this takes time. Consistent behaviour minimises time misspent on wild goose chases.
And yes to the case issue because there is a case sensitivity control - my choice, not a random variable to be explored.
It is indeed a very minor thing for me, but simply by documenting it I thought I might save someone else time, confusion and frustration. Also - how do I know what looks minor is in fact so for everyone else or the codebase? Maybe the same underlying fault causes bigger problems elsewhere?