@Nishya There’s no issue created, since there’s no steps-to-reproduce.
Greetings everyone.
I can’t say for sure what caused the issue, but I encountered the same.
While users are able to execute all kind of queries, they were unable to save Questions unless they were the SQL kind or they were Administrators - this was present only for BigQuery Datasources.
There were three variables for us: we updated metabase version to 36.x, migrated from .jar execution to Docker (didn’t change the Metabase Database), updated BigQuery access from OAuth to Service Accounts.
The workaround: created new User Groups.
Switching Group permissions on and off or adding and removing users from groups did not work, but creating a new group did.
I will keep you posted if I find more information.
Edit: i checked the permissions_group, permissions and permissions_group_membership and didn’t find any difference between the records of previously existing groups and the new one.
Regards
Very interesting. And a little strange that you didn’t see any differences in the group tables that could indicate what the problem is.
- Which version did you upgrade from?
- Do you still have the old (problematic) application database? This could be very useful to figuring out the metadata difference between the working application database.
From your information, I have a feeling that this is caused by a missing constraint in the application database, which somehow have caused a permission change to not correctly update.
This can be checked by looking in the table databasechangelog, where the MARK_RAN might have been applied, but if you check the schema of the change, then you don’t see the added/removed constraint.
We’ve seen an issue, where the migration steps wasn’t executed correctly, which can lead to schema inconsistency and result in various problems:
https://github.com/metabase/metabase/issues/13043
- We upgraded from 0.34.3
- Yes, we did not make any changes to the application database, that I know of. We simply changed the Metabase version and running environment using the same database connection parameters (environment variables). That must have prevented migrations from being applied.
The database is Postgres, the last MARK_RAN exectype was on July 24th, while the last (and actual) upgrade in Metabase was on October 14th. Finally, the last records on databasechangelog were on October 6th and were only of exectype EXECUTED.
I’m sorry I can’t give you more detailed information because we tried some changes in Metabase to increase query timeout limit and that was only successful when we changed our environment.
The exectype records I mentioned were probably result of some tries of upgrading Metabase through its own interface.
In case this might be helpful:
{
"browser-info": {
"language": "pt-BR",
"platform": "Win32",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36",
"vendor": "Google Inc."
},
"system-info": {
"file.encoding": "UTF-8",
"java.runtime.name": "OpenJDK Runtime Environment",
"java.runtime.version": "11.0.8+10",
"java.vendor": "AdoptOpenJDK",
"java.vendor.url": "https://adoptopenjdk.net/",
"java.version": "11.0.8",
"java.vm.name": "OpenJDK 64-Bit Server VM",
"java.vm.version": "11.0.8+10",
"os.name": "Linux",
"os.version": "5.4.0-1028-gcp",
"user.language": "en",
"user.timezone": "GMT"
},
"metabase-info": {
"databases": [
"googleanalytics",
"bigquery",
"postgres",
"sqlserver",
"mysql"
],
"hosting-env": "unknown",
"application-database": "postgres",
"application-database-details": {
"database": {
"name": "PostgreSQL",
"version": "9.6.18"
},
"jdbc-driver": {
"name": "PostgreSQL JDBC Driver",
"version": "42.2.8"
}
},
"run-mode": "prod",
"version": {
"date": "2020-09-15",
"tag": "v0.36.6",
"branch": "release-0.36.x",
"hash": "cb258fb"
},
"settings": {
"report-timezone": null
}
}
}Hello,
We upgraded to version v0.36.6 and we still have the same issue.
Regards,
@shigah I feel like a broken record. Without steps to reproduce, then it’s very difficult to figure out what the problem is and how to fix it.
Anyone is more than welcome to open an issue on this, but again, without steps-to-reproduce, then it will be very difficult to fix.
https://github.com/metabase/metabase/issues/new/choose
Just for clarity: Steps to reproduce means that anyone should be able to reproduce the problem on their instance
flamber, is there any way to check for failed migrations (or pending ones) without trying to run a new instance of metabase?
I am considering that a solution would be start a new application database and populate with the existing database data (after the tables were created).
@alexandreb11 You would have to look through every single migration with MARK_RAN and then validate if the schema actually has that change too. Also check the database log for any errors during.
@Nishya: I have the same issue, and i think i was able to solve it. Need to prove tomorrow if it is really the root cause. I faced this problem with an oracle instance I connect over metabase wich is on oracle 19c. All other oracle instances we are connected to are 12c and 11.
Those worked very well, but the 19c one user wasn’t able to save questions, even though he had all the permissions set. The only thing I saw is that a table had in the 19c database has data type nvarchar 16 byte instead of 16 char. I changed this to 16 char, and i think this solved the problem. But in the meanwhile i tried so many things, so i am not sure if this is the real root cause 
. Maybe all of you having the same problem are you facing the same problem with a oracle you are connecting to?
@flamber
guys, good afternoon. can you help me?
When I save, a question created in '' Simple question "appears an error message: You are not able to run native ad-hoc queries against database 3."
I already sent the Log and you said that you cannot reproduce it. I use Metabase version v0.36.3 and continue with the Bug.
I have access to the bank and all tables.
Where can I give permission to run ad-hoc queries?
@brunasiq I don’t see any “Diagnostic Info” or logs you have posted. Latest release is 0.37.5
Did you read the comment about creating a new user group seems to fix the problem?
It would be create if someone could make a dump of their application database before and after, and compare the data, so we can figure out what is causing this and create a fix for it.
Too all:
If anyone is still experiencing this problem, please upgrade to 0.38.3, which has tried to fix the problem and also provide much more logging, if the problem still happens.
https://github.com/metabase/metabase/releases/tag/v0.38.3
If you are still experiencing the problem on 0.38.3, then please provide the logs from Admin > Troubleshooting > Logs, which should help us understand what is the root cause of this.