SearchKit - Support implied operators in exposed search forms #19959
Conversation
Previously, default help_pre and help_post would not show if set for a custom field.
|
(Standard links)
|
|
@colemanw style issue |
| }; | ||
| defn.input_attrs = _.isEmpty(defn.input_attrs) ? {} : defn.input_attrs; |
There was a problem hiding this comment.
are we switching from an empty array to an empty object here?
There was a problem hiding this comment.
Yes the former was a mistake made by my php-centric brain.
|
I gave this a quick spin & it seems to work fine although I note that
@colemanw I don't consider the above to be blocking although the first is perhaps 'near blocking'. I'm happy to merge & leave those things out of scope if you want |
This adds support for filter operators in SearchKit. It does not expose an operator selector to Afform but allows an operator to be implied through the type of field configured. e.g. a multiselect implies the IN operator & a range select implies BETWEEN.
Search display forms only allow numeric fields to be a search range, but postal code is an exception (it's stored as a string but is numeric in some locales)
|
@eileenmcnaughton I've fixed |
|
I've retested & 1 is fixed 3 is quasi fixed - see how 900 is included here - I don't think addressing that needs to be in scope so I'm merging
|
Overview
This opens up a lot more possibilities for exposed filters with searchKit displays.
Before
Only single-value filters accepted.
After
New "Multi-Select" and "Search by range" options will allow searches like
IN(...)orBETWEEN [...]respectively.The most complex one is Date fields, which allows you to change the widget to Select and enable "Search by range". If you do both then you get the familiar dropdown of relative dates plus a "Choose Date Range" option:
Technical Details
Adds a basic unit test to ensure operators are functioning.
Comments
This doesn't implement exposed filters, but it doesn't box us out of that possibility either. The filter syntax will accept operators.