Add Support for Case-insensitive `contains` dashboard filters (#24582)
* Dashboard Card String Filters are now case-insensitive
This PR is a draft because while it solves the problem of string filters being case sensitive, it doesn't necessarily
do it in the best way.
This isn't necessarily
a bug, but it seems that there is no way for the frontend to set the :case-sensitive true/false option anyway.
For the purposes of this initial attempt at a solution, I have modified the endpoint
` POST "/:dashboard-id/dashcard/:dashcard-id/card/:card-id/query"` to automatically include an option map containing
:case-sensitive false.
The machinery to take this option into consideration already exists with the default :sql ->honeysql function in the `
metabase.driver.sql.query-processor` namespace. See the `like-clause` private function in particular.
Since the query processor is a bit opaque to me at present, I was unable to figure out if there is a proper way that
the frontend could send an options map (or key-value pair) all the way through the qp middleware to the query building
stage. I discovered that if you conj a map `{:case-sensitive false}` to the output of the `to-clause` function in
`metabase.driver.common.parameters.operators`, you will get the desired case-insensitive behavior. So, I modified the
to-clause function in this PR to appropriately conj an options map if one exists.
What I'd like to know:
- is there a super-simple way to pass an option in already that I just missed? (eg. I thought perhaps in the `[:field
13 nil]` that 'nil' could be an options map, but I couldn't get that to work for me)
- is there a middleware approach that I should consider?
- any other options to appropriately hanlde this?
* Revert the endpoint.
If the frontend sends an options map on an options key inside the parameter, this endpoint will pass that on, so no
change is needed.
* include parameter options in datasetQuery
Co-authored-by:
Adam James <adam.vermeer2@gmail.com>
Please register or sign in to comment