You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Question will give a error about a parameter not set in some position just because variable "{{a}}", for example, is in both questions (called and nested).
Logs
None... (Didn't save it 馃槩)
To Reproduce
Steps to reproduce the behavior:
*#=n is an arbitrary question number.
Create the following questions:
1.a QUESTION (#=13) a:
select1 [[, @a:={{a}}]]
b QUESTION (#=14) b:
select*from (select1 [[, @a:={{a}}]]) temp,{{#13}} a
Run question b (#=14) and see the error message on the screenshot.
Expected behavior
Make it so it doesn't conflict with nested queries parameters (Isolated variables as in previous versions).
This behavior didn't happen in 0.35.4.
Severity
We downgraded from 0.36.6 to 0.35.4 because of that...
Additional context
I use the pattern above to propagate values to nested questions and filter them in the root, so that my entire dashboard is related to the same datasource.
Setting @A, for example, make it possible to use it in nested queries. Cool! Isn't it?
I can see that something made this hack stop working in 0.36.0. Not sure what could have caused that though.
It鈥檚 currently not supported to pass-thru filters from Saved Questions or Sub-Query variables - #4367/#6449
I don't think we are going to fix this hack, since it would preferable to be able to pass-thru filters more generally. Closing.
Describe the bug
Question will give a error about a parameter not set in some position just because variable "{{a}}", for example, is in both questions (called and nested).
Logs
None... (Didn't save it 馃槩)
To Reproduce
Steps to reproduce the behavior:
*#=n is an arbitrary question number.
1.a QUESTION (#=13) a:
Expected behavior
Make it so it doesn't conflict with nested queries parameters (Isolated variables as in previous versions).
This behavior didn't happen in 0.35.4.
Screenshots
Information about your Metabase Installation:
wrong version info... sorry 馃槥 guess i won't be given you guys that... (we downgraded)
{"browser-info": {
"language": "en-US",
"platform": "Win32",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0",
"vendor": ""
},
"system-info": {
"file.encoding": "UTF-8",
"java.runtime.name": "OpenJDK Runtime Environment",
"java.runtime.version": "11.0.7+10",
"java.vendor": "AdoptOpenJDK",
"java.vendor.url": "https://adoptopenjdk.net/",
"java.version": "11.0.7",
"java.vm.name": "OpenJDK 64-Bit Server VM",
"java.vm.version": "11.0.7+10",
"os.name": "Linux",
"os.version": "4.19.112+",
"user.language": "en",
"user.timezone": "UTC"
},
"metabase-info": {
"databases": [
"h2",
"mysql"
],
"hosting-env": "unknown",
"application-database": "mysql",
"application-database-details": {
"database": {
"name": "MySQL",
"version": "5.7.25-google-log"
},
"jdbc-driver": {
"name": "MariaDB Connector/J",
"version": "2.5.1"
}
},
"run-mode": "prod",
"version": {
"date": "2020-05-28",
"tag": "v0.35.4",
"branch": "release-0.35.x",
"hash": "b3080fa"
},
"settings": {
"report-timezone": "America/Sao_Paulo"
}
}
}
Severity
We downgraded from 0.36.6 to 0.35.4 because of that...
Additional context
Setting @A, for example, make it possible to use it in nested queries. Cool! Isn't it?
The text was updated successfully, but these errors were encountered: