Various changes to support refactoring CMS search filter functionality #11587
+268
−94
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.
Important
There are a few commits here. Do not squash.
Commit 1: API Make SearchContext::individualFieldSearch() protected.
This is needed to allow a SiteTree-specific search context to add custom logic for a specific field, while falling back to this default logic for everything else.
Commit 2: API Provide minimum and maximum comparison values for numeric DBFields
This will be used with handling WithinRangeFilter in searchable fields so that if only one of the two ends of a range is filled in, the other can be automatically populated.
Commit 3: NEW Handle WithinRangeFilter in searchable_fields and SearchContext
This is especially helpful with date ranges, e.g. all records edited within a certain range, but can be used out of the box with basically any numeric, date, or time-based fields. This is required to support filtering against
LastEdited
for pages in the same way they currently do.Commit 4: FIX Ensure composite fields have their values filled in the search form
In the CMS search filter, composite fields would always appear empty after submitting the form because their prefix was missing. This could also introduce conflicts if a same-named field was in the main edit form.
Issue
CMSMain
/HierarchyModelAdmin
silverstripe-cms#2949