As a user, I expect search strings to match non-word boundaries in searchable dropdown lists

Is there a spec for how the search should work? It seems this match would only work if "." is regarded as a separator character. Then I can easily see another JIRA complaining that "b" matches "a.b.c.d.e" when it shouldn't.

In general, I would expect a search query always matching any occurrence, i.e. "b" should match "a.b.c.d.e".
For anything that does not work on pure strings, the user would need to know why to understand why a string match does not results in a search match. So why should "b" then not match "a.b.c.e.d" in your example? Without such an explanation, users will always report it as a bug to our experience. And even if this is all documented well, it won't prevent users from not reading the documentation and report it as a bug

So the spec is: If the search query (in means of a sequence of characters) is a substring (in means of the same sequence of characters), this implies a search match.

I was thinking of the Series search in the table (didn't read properly, like those users!).

So you're saying that that drop-down fields (I assume all drop-down fields, not just Series and not just in event metadata?) should use substring matching?

The behaviour in other fields seems a bit inconsistent, e.g. in License, you get matches from "BY" but not "NC" whereas the Presenter field seems to have proper substring matching.

The series dropdown already has substring matching (e.g. Recordings->Events->"Add Event"->Field:Series). But it does not work consistently, e.g. "18" does match "FS 18.3101.12", but "3101" doesn't.

> So you're saying that that drop-down fields (I assume all drop-down fields, not just Series and not just in event metadata?) should use substring matching?

I would be desirable that all fields behave the same, so yes, I would go for substring matching everywhere. At least, I haven't found an example where it would not be appropriate.

Merged as PR 1516 (commit 9d2ca32 )