Align PublicBody search between views and API #1196
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Search is currently handled differently in regular views and API views, which leads to inconsistent search results depending on whether a search is performed via the search form or through the API.
This is especially the case for
PublicBody(see https://github.com/fragdenstaat/issues/issues/293). In the API view,get_searchquerysetis overridden with a custom search and filtering configuration. As a result, recent changes to the search analyzers are not applied there. UsingPublicBodyFilterSetinstead, as in the view, could resolve this.However, I noticed several differences between
PublicBodysearch in views and in the API (which is also why the tests I added are currently failing):multi_matchsearch, while the rest of the application appears to usesimple_query_string.PublicBodyFilterSetuses slugs (which seems to be consistent with other API endpoints, e.g. forFoiRequest).categoriesin the API butcategoryinPublicBodyFilterSet.regionsandregions_kindexist in the API, but not inPublicBodyFilterSet.I’m unsure how to resolve these differences without breaking the API, and which parts are still intentional vs. legacy behaviour.
@stefanw Could you take a look?