Feat/search criteria and endangered filter#439
Merged
Conversation
Allow callers to request inscription-criteria filtering on heritage search. The factory rejects values outside the i-x whitelist so invalid input fails fast before reaching Algolia. Also updates the consuming factory and search-heritages tests for the new constructor argument. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Without indexing the criteria attribute, any criteria facet filter would always return zero hits because the field would not exist on Algolia records. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Multiple selected criteria are joined with OR (criteria:i OR criteria:iv ...) so a request for "i or iv" returns heritage sites whose criteria contain either value, matching the certification-exam study flow. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wire criteria through the application and presentation layers so clients can pass criteria[]=i&criteria[]=iv on the search endpoint. The controller normalises a single string value into a one-element array for callers that send a non-array form. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Feat/add criteria filter algolia
Allow callers to filter heritage search by endangered status. The factory only forwards the value because the ?bool type hint already guards against unsupported inputs at the language level. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Translate the boolean isEndangered into a single Algolia facet condition (is_endangered:true or is_endangered:false) so users can narrow heritage search to the World Heritage in Danger list, matching a common certification-exam study flow. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ller Wire isEndangered through the application and presentation layers so clients can pass is_endangered=true|false on the search endpoint. The controller distinguishes "absent" from "false" by checking presence before reading the boolean, so omitting the parameter preserves the existing all-records behaviour. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The split-json command was silently dropping the raw UNESCO 'danger'
field, so every imported site ended up with is_endangered=false in
MySQL and Algolia. The new is_endangered facet filter would have
returned zero hits in production for that reason.
Read row['danger'] in normalizeSiteRowImportReady, OR-merge it across
duplicate rows in mergeSiteRowPreferExisting (so any row carrying
danger:true wins), and add a boolFromDanger helper that accepts
boolean and string forms ("True", "true", "1", "yes") UNESCO emits.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ship the 1248 Japanese short descriptions as a slim 898 KB JSON so the translate command can restore them on production without paying for Google Translate API. Extracted from the local 19 MB world_heritage_sites_translation.json (kept untracked as working state) by stripping every field except id_no and short_description_ja. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Point the --from-json branch of the translate command at the checked-in 898 KB short_description_ja.json instead of the local 19 MB world_heritage_sites_translation.json. Behaviour is unchanged because description_ja was already null for every record in the full file; the slim file just trims fields that were never used and ships the cache to production. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Commit the 19 MB UNESCO snapshot with spliced Japanese translations so the file is available on the production host without re-running the local dump. Used as the working backup that the translate command writes back to; the slim short_description_ja.json remains the canonical --from-json source. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The frontend serialises multi-select criteria as criteria=i,ii,iii,iv (comma-separated). The previous single-string fallback wrapped the whole string in a one-element array, making it fail the i-x whitelist validation in AlgoliaSearchListQueryFactory. Split on comma so each code is validated and forwarded to the Algolia OR filter individually. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…algolia `is endangered` filter search algolia
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
No description provided.