Bring the membership lookup in line with the existing repo convention
for set types (see services/thumbnails/pkg/thumbnail/mimetypes.go for
the same pattern). Storing struct{} values instead of bool makes the
set semantics explicit and rules out accidental false entries.
Copilot review pointed out that the comment claimed pre-lowercasing
makes non-analyzed query types (wildcard, fuzzy) match for every
allowlisted field. That is true for Name/Tags/Favorites, whose
lowercaseKeyword analyzer emits a single lowercased token, but the
Content analyzer also stems terms — so the guarantee doesn't hold
there. Drop the specific claim and keep the comment to the intent:
stay consistent with the field's analyzer.
The bleve compiler lowercased every query value (except Hidden)
before handing it to the engine. This matched the index tokens
for fields whose analyzer folds case — Name, Tags, Favorites,
Content — but silently broke matching for every other field,
whose default keyword analyzer preserves case. A query like
Title:"Some Title" parsed fine, lowercased to "some title", and
missed the indexed token "Some Title".
Replace the blanket lowercasing with an allowlist of the four
fields whose index mapping actually uses a lowercasing analyzer.
Every other field now passes through unchanged, which keeps
values like "deadmau5" or "Motörhead" intact instead of
normalising them to a case the tag writer didn't choose.
* enhancement: use kql as default search query language
* enhancement: add support for unicode search queries
* fix: escape bleve field query whitespace
* fix: search related acceptance tests
* enhancement: remove legacy search query language
* enhancement: add support for kql dateTime restriction node types
* chore: bump web to v8.0.0-alpha.2
* fix: failing search api test
* enhancement: search bleve query compiler use DateRangeQuery as DateTimeNode counterpart
* enhancement: support for colon operators in dateTime kql queries
* feat(search): introduce search query package
With the increasing complexity of how we organize our resources, the search must also be able to find them using entity properties.
The query package provides the necessary functionality to do this.
This makes it possible to search for resources via KQL, the microsoft spec is largely covered and can be used for this.
In the current state, the legacy query language is still used, in a future update this will be deprecated and KQL will become the standard
