Field filter breaks native question on dashboard #40383
Assignees
Labels
.Escalation
Priority:P1
Security holes w/o exploit, crashing, setup/upgrade, login, broken common features, correctness
Querying/Parameters & Variables
Filter widgets, field filters, variables etc.
Querying/
.Regression
Bugs that were previously fixed and/or bugs unintentionally shipped with new features.
.Team/QueryProcessor
:hammer_and_wrench:
Type:Bug
Product defects
Milestone
Comments
zbodi74
added
Type:Bug
perivamsi
added
.Team/QueryProcessor
snoe
added a commit
that referenced
this issue
Mar 22, 2024
Fixes #40383 If a native query parameter is set up with a string widget type that supports a `case-sensitive` option, and that parameter is tied to a dashboard filter that did not support that option, the option was still leaking into the filter as an option where options were not expected. For instance the native query parameter used `string/contains` and the dashboard used `string/=`, the QP would try to build a filter like `[:= field value {:case-sensitive false}]` which is an illegal filter.
snoe
added a commit
that referenced
this issue
Mar 25, 2024
Fixes #40383 If a native query parameter is set up with a string widget type that supports a `case-sensitive` option, and that parameter is tied to a dashboard filter that did not support that option, the option was still leaking into the filter as an option where options were not expected. For instance the native query parameter used `string/contains` and the dashboard used `string/=`, the QP would try to build a filter like `[:= field value {:case-sensitive false}]` which is an illegal filter.
github-actions bot
pushed a commit
that referenced
this issue
Mar 25, 2024
Fixes #40383 If a native query parameter is set up with a string widget type that supports a `case-sensitive` option, and that parameter is tied to a dashboard filter that did not support that option, the option was still leaking into the filter as an option where options were not expected. For instance the native query parameter used `string/contains` and the dashboard used `string/=`, the QP would try to build a filter like `[:= field value {:case-sensitive false}]` which is an illegal filter.
metabase-bot bot
added a commit
that referenced
this issue
Mar 26, 2024
* Fix case-sensitive option leaking to string/= (#40535) Fixes #40383 If a native query parameter is set up with a string widget type that supports a `case-sensitive` option, and that parameter is tied to a dashboard filter that did not support that option, the option was still leaking into the filter as an option where options were not expected. For instance the native query parameter used `string/contains` and the dashboard used `string/=`, the QP would try to build a filter like `[:= field value {:case-sensitive false}]` which is an illegal filter. * Fix moved fn --------- Co-authored-by: Case Nelson <case@metabase.com> Co-authored-by: Chris Truter <crisptrutski@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Field filters break native question on a dashboard
To Reproduce
select * from products where {{ title }}, set the variable type to Field Filter, wire it toProducts.Title.Title.4(!) Set a value for the title, and see the error
.../query api response:
"error": "Error compiling HoneySQL form: These SQL clauses are unknown or have nil values: :case-sensitive",Expected behavior
It should work.
Logs
.../queryresponse: query_response.jsonInformation about your Metabase installation
Appears to be broken on stats as of 2024-03-20 /
4eea910,1.48.8,1.48.9and1.49.0.Severity
P1
Additional context
No response
The text was updated successfully, but these errors were encountered: