Search enhancements: faceting, relevance tuning, and a public search endpoint #35

New Issue

2026-06-04T10:54:43Z

logaritmisk commented

2026-06-04 10:54:43 +00:00

Context

Milestone 5 delivered admin full-text search (GET /api/admin/search, ViewInternal) with a single text query + a visibility filter. Several richer capabilities were deliberately left out of M5 scope. Tracking them here as a backlog of distinct, independently-schedulable pieces (split into separate issues when picked up).

Candidates

Faceting + facet counts. Beyond visibility: filter/aggregate by object_name, current_owner, has-images, date ranges, and show counts per facet value. Requires declaring facet/filterable attributes on the Meilisearch index (SearchClient::ensure_index currently only sets visibility filterable) and exposing facet distributions through the endpoint + UI.
Relevance tuning. Configure Meilisearch ranking rules, typo tolerance, synonyms, and searchable-attribute ordering (e.g. weight object_name/object_number above flattened fields_text). Currently the index uses defaults.
Public search endpoint (GET /api/public/search). The M5 endpoint is admin-only and searches all visibility levels. A public-facing site would need a search restricted to visibility = public, mirroring the public::list_objects access model. Pairs with any future public website.
Search query analytics / logging — what users search for, zero-result queries (to inform synonyms/vocabulary), etc.

Notes

The on-write index sync (reindex in crates/api/src/lib.rs) and reindex_all recovery path already keep the index current; these enhancements are about query richness and index configuration, not freshness.
#27 (searchable term/authority picker) is related but distinct — that's a combobox over vocab/authorities, not catalogue-object search.

## Context Milestone 5 delivered admin full-text search (`GET /api/admin/search`, `ViewInternal`) with a single text query + a visibility filter. Several richer capabilities were deliberately left out of M5 scope. Tracking them here as a backlog of distinct, independently-schedulable pieces (split into separate issues when picked up). ## Candidates 1. **Faceting + facet counts.** Beyond visibility: filter/aggregate by `object_name`, `current_owner`, has-images, date ranges, and show counts per facet value. Requires declaring facet/filterable attributes on the Meilisearch index (`SearchClient::ensure_index` currently only sets `visibility` filterable) and exposing facet distributions through the endpoint + UI. 2. **Relevance tuning.** Configure Meilisearch ranking rules, typo tolerance, synonyms, and searchable-attribute ordering (e.g. weight `object_name`/`object_number` above flattened `fields_text`). Currently the index uses defaults. 3. **Public search endpoint** (`GET /api/public/search`). The M5 endpoint is admin-only and searches all visibility levels. A public-facing site would need a search restricted to `visibility = public`, mirroring the `public::list_objects` access model. Pairs with any future public website. 4. **Search query analytics / logging** — what users search for, zero-result queries (to inform synonyms/vocabulary), etc. ## Notes - The on-write index sync (`reindex` in `crates/api/src/lib.rs`) and `reindex_all` recovery path already keep the index current; these enhancements are about *query richness* and *index configuration*, not freshness. - #27 (searchable term/authority picker) is related but distinct — that's a combobox over vocab/authorities, not catalogue-object search.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: logaritmisk/biggus-dickus#35