Tested and this issue seems to be real: I have a dashboard with 8+ filters. I have specified ‘A list of values’ on Field Settings under data model for that SQL Server table. When I update and Rescan fields and then go back to the dashboard, it works. Revisit that dashboard 30 min later (not sure on exact time) and the Filters on the dashboard are not providing a list any more, just a ‘Plain Input box’, even though setting in the Data Model is still ‘A List of Values’
Using Metabase v0.32.8 Chrome Version 74.0.3729.157 and Firefox 66.0.3
If I go back to the Data Model area and to the specific field that is not displaying correctly, and click ‘Rescan the Field’, it works properly for a short while.
Hi @Slickrock22
Do you see anything in the log, which could indicate the problem?
There’s a few issues open about filter dropdowns not working, but most of those are because you currently cannot have a filter on multiple cards with different tables.
I think crossing datasets was probably the issue. I didn’t realize that this was a limitation. I removed the filters from those that cross over and it seems to work now.
@Slickrock22
Like I said, there’s multiple issues open about cross filtering - they’re all related - go and upvote by clicking 
on the first post (please don’t comment unless it’s relevant):
https://github.com/metabase/metabase/issues/5677
https://github.com/metabase/metabase/issues/7168
1 Like
I just experienced this issue again. Filter boxes flipped back to Input Boxes vs dropped downs. Tried re-scanning fields and it didn’t help. I created a new dashboard and added one gauge and added one filter (same filter on another dashboard that changed to a text input box). Saved. The new filter on the new dashboard worked perfectly. Went back to the Old Dashboard and filter was now a drop down box. Other filters did not. Added a second filter to the new Dashboard (same filter on another dashboard that changed to a text input box) and saved. Looked back at old Dashboard and now only those two filters work correctly with Drop downs. Thought it might be caused by having two questions on a dashboards from two data sources (Datasource A and Datasource B), even though the Datasource A Filter was not applied to Question B on Dashboard. New Dashboard filters still worked. I then Applied Datasource A’s filters to Question B and save. Filters correctly and Filters stayed as Dropdown list boxes.
This seems to be random. Using SQL Server as back-end. Not sure what to look for in the logs.
@Slickrock22
It sounds like you might be seeing multiple issues. One is multiple data sources, and the other is “disappearing” dropdown.
If you check your log, then you should check when Metabase does a sync/scan, to see if something caused it to flush all the values.
You can dig into the metadata table metabase_fieldvalues to see the current values.
You are not using SQL Server as your back-end (aka metadata database) - currently only H2 (default), Postgres and MariaDB/MySQL is supported.
I guess you mean, you’re using SQL Server as your data source.
I have Metabase running multiple places, where SQL Server is the data source too, and I have 20+ questions per dashboard with filters. All those questions are using different tables, but I’ve made LEFT JOINs to connect to the same Field Filter table+column everywhere.
OK. The values look properly populated in metabase_fieldvalues table. The only errors that I see in the log are the following from yesterday. It does look like it relates to the other two report issues. I am experiencing the same problems.
Jun 05 02:50:17 ERROR metabase.middleware.log :: PUT /api/metric/2 500 8 ms (1 DB calls)
{:message “Wrong number of args (1) passed to: metabase.mbql.normalize/fn–20700”,
:type clojure.lang.ArityException,
:stacktrace
(“clojure.lang.AFn.throwArity(AFn.java:429)”
“clojure.lang.AFn.invoke(AFn.java:32)”
“clojure.lang.AFn.applyToHelper(AFn.java:154)”
“clojure.lang.AFn.applyTo(AFn.java:144)”
“clojure.core$apply.invokeStatic(core.clj:665)”
“clojure.core$apply.invoke(core.clj:660)”
“–> mbql.normalize$canonicalize_mbql_clauses$fn__20704.invoke(normalize.clj:486)”
“mbql.normalize$canonicalize_mbql_clauses.invokeStatic(normalize.clj:478)”
“mbql.normalize$canonicalize_mbql_clauses.invoke(normalize.clj:475)”
“mbql.normalize$canonicalize.invokeStatic(normalize.clj:501)”
“mbql.normalize$canonicalize.invoke(normalize.clj:496)”
“mbql.normalize$normalize_fragment.invokeStatic(normalize.clj:608)”
“mbql.normalize$normalize_fragment.invoke(normalize.clj:599)”
“mbql.normalize$normalize_fragment.invokeStatic(normalize.clj:609)”
“mbql.normalize$normalize_fragment.invoke(normalize.clj:599)”
“models.interface$normalize_metric_segment_definition.invokeStatic(interface.clj:87)”
“models.interface$normalize_metric_segment_definition.invoke(interface.clj:85)”
“api.metric$write_check_and_update_metric_BANG_.invokeStatic(metric.clj:80)”
“api.metric$write_check_and_update_metric_BANG_.invoke(metric.clj:68)”
“api.metric$fn__49938.invokeStatic(metric.clj:99)”
“api.metric$fn__49938.invoke(metric.clj:85)”
“middleware.auth$enforce_authentication$fn__59926.invoke(auth.clj:14)”
“routes$fn__61084$fn__61085.doInvoke(routes.clj:56)”
“middleware.exceptions$catch_uncaught_exceptions$fn__60017.invoke(exceptions.clj:104)”
“middleware.exceptions$catch_api_exceptions$fn__60014.invoke(exceptions.clj:92)”
“middleware.log$log_api_call$fn__61458$fn__61459.invoke(log.clj:170)”
“middleware.log$log_api_call$fn__61458.invoke(log.clj:164)”
“middleware.security$add_security_headers$fn__59980.invoke(security.clj:105)”
“middleware.json$wrap_json_body$fn__61163.invoke(json.clj:61)”
“middleware.json$wrap_streamed_json_response$fn__61181.invoke(json.clj:97)”
“middleware.session$bind_current_user$fn__58593$fn__58594.invoke(session.clj:193)”
“middleware.session$do_with_current_user.invokeStatic(session.clj:176)”
“middleware.session$do_with_current_user.invoke(session.clj:170)”
“middleware.session$bind_current_user$fn__58593.invoke(session.clj:192)”
“middleware.session$wrap_current_user_id$fn__58582.invoke(session.clj:161)”
“middleware.session$wrap_session_id$fn__58567.invoke(session.clj:123)”
“middleware.auth$wrap_api_key$fn__59934.invoke(auth.clj:27)”
“middleware.misc$maybe_set_site_url$fn__61523.invoke(misc.clj:58)”
“middleware.misc$bind_user_locale$fn__61526.invoke(misc.clj:74)”
“middleware.misc$add_content_type$fn__61511.invoke(misc.clj:30)”
“middleware.misc$disable_streaming_buffering$fn__61548.invoke(misc.clj:119)”
“middleware.misc$wrap_gzip$fn__61541.invoke(misc.clj:101)”)}
@Slickrock22
You would probably have to look at what values are populated, when it doesn’t work.
You can ignore that error, that’s a different issue - 9743
Without seeing your queries and knowing which Filter Filter references you’re using, I wouldn’t know why you’re having problems.
Ok. Thanks for the quick responses. I was using 2 very similar tables. One that was a process summary table (think flat like excel 1 row per record) and another table with nearly the same data that is more normalized (30 rows per record) with really only two additional columns that differentiate it from the summary table. I simply added a new column in the detail table called Type (with values of either Master or Detail) and loaded both Summary and Detail data into one table (no crossing). Updated the Dashboard to no longer cross over two different data sources and the filter boxes didn’t revert to drop downs. Tried ‘sync database schema now’, ‘re-scan filed values now’. I also went into the model and attempted to change the ‘Filtering on this field’ spec to input box, then back to ‘List of all values’ and nothing. Do I need to rebuild the dashboard from scratch to get my dropdown filters back?
@Slickrock22
Like I said, without seeing the queries and Field Filters, then I don’t know.
What if you refresh the browser, when you’re on the Dashboard? Someone wrote that it worked for them sometimes.
But for the dropdown to work, you need to reference the exact same table and column in the Field Filter. Example:
Query 1:
SELECT * FROM orders
LEFT JOIN people ON people.id=orders.people_id
WHERE {{filter}} --NOTE: the filter reference could be people.name
Query 2:
SELECT * FROM reviews
LEFT JOIN people ON people.id=reviews.people_id
WHERE {{filter}} --NOTE: the filter reference could be people.name
Thanks. I am not using any custom SQL. All of it is using the UI for building reports. Have I understood your question correctly?
Different tables are different data sources - issue 5677
Sorry I didn’t do a good on explaining it clearly. I understood that. I am now using only 1 table for the data source on all of the cards on the dashboard with the filters. The drop downs do not come back.
I just deleted a filter and added it back. Re-associated to the cards and now its a drop down again. If in fact this is error is created by a user using two cards with different data sources on a single dashboard, without any restrictions from Metabase this will be a constant problem. Non-Technical users will always attempt to cross data sources on a single dashboard. What I think needs to be clear is how to unwind without having to build your dashboard from scratch to recover drop downs. Any thoughts on what in the DB is actually causing the disappearance of drown down values?
@Slickrock22
I haven’t debugged this issue, but I’m guessing there are some changes in the metadata - my first guess would be in report_dashboardcard
There are more than 2000 open issues, so this is not the only issue that might be hitting non-technical users. It’s a constant battle with prioritizing development resources.
And Metabase is being developed by a small team - with help from the community.
While this bug has 0.33 as milestone, then it’s no guarantee it will be fixed by that version - there are currently 58 other issues also scheduled for that milestone:
https://github.com/metabase/metabase/milestone/75
Totally Understand and to be honest I am quite surprised by your responsiveness…Thank you!! Have an awesome night!
One quick question. In what table is the relationship between the dashboard filter and the card filter field selected stored?
@Slickrock22
From what I can see, the dashboard filter (it’s called parameter internally) is stored in report_dashboard.parameters (here you see ..."id":"35523ff1"...) and then you have individual card references in report_dashboardcard.parameter_mappings (here you see ..."parameter_id":"35523ff1"...)
on the first post (please don’t comment unless it’s relevant):