Bug description
I built the custom image from superset repo. The steps that I followed
- Create a dummy user
- Create a custom role to give access to only a single table under dataset and assign this new role to dummy user
- Try logging in with dummy user. You can see dataset under the sqllab screen but not able to see table name there. PFA attached screenshot
- if you run query from sqllab screen, it works for that particular table.
Screenshots/recordings
No response
Superset version
master / latest-dev
Python version
3.11
Node version
16
Browser
Chrome
Additional context
No response
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [ ] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
I found a similar closed issue titled "SqlLab preview permissions error" on the Superset GitHub repository. However, no solution was found in the comments of that issue [1]. You might want to check if there are any updates or additional comments that could be relevant to your situation.
To continue talking to Dosu, mention @dosu.
Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other
Comment From: rusackas
Wondering if this might solve it.
Comment From: ts-saurabhkdm
I can test that branch to see if it solves the issue.
Comment From: ts-saurabhkdm
@rusackas This above fix/PR does not solves the existing issue.
Comment From: codenamelxl
You can check whether your SQLLab contains these permission
can post on TableSchemaView
can delete on TableschemaView
can expaned on TableschemaView
If you apply the above PR after your DB was inited. You need to run superset init again to give SQLLab role the extra permissions
Comment From: ts-saurabhkdm
@codenamelxl This does not fix mentioned issue. Issue is more like let's assume I have 10 table, I created role for 1 table when I applied role like that to non-admin user who has access to only sqllab. It can not see tableschema but with your mentioned permission it just give access to all 10 tables which is bad idea for us. This feature was working till V4.1
Comment From: codenamelxl
@codenamelxl This does not fix mentioned issue. Issue is more like let's assume I have 10 table, I created role for 1 table when I applied role like that to non-admin user who has access to only sqllab. It can not see tableschema but with your mentioned permission it just give access to all 10 tables which is bad idea for us. This feature was working till V4.1
Could you check whether you also grant database access on ... or schema access on ... to that user?
The MR only grant permissison for sql_lab to see the table schema, it does not control what table the user can see.
Comment From: ts-saurabhkdm
problem here is cosmetic. End users can query tables but tables are not popping in the list. It always list empty table.
Comment From: codenamelxl
problem here is cosmetic. End users can query tables but tables are not popping in the list. It always list empty table.
Somewhat cosmetic . #32340 fix this issue. Your issue with user can see all table schema is a different topic.
Comment From: ts-saurabhkdm
problem here is cosmetic. End users can query tables but tables are not popping in the list. It always list empty table.
Somewhat
cosmetic. #32340 fix this issue. Your issue with user can see all table schema is a different topic.
Thank you for fixing this issue. I am sorry but description clearly mentions my issue. Tagging different issue with this issue here is wrong. This feature got lost in past upgrades. I remember this was working correctly in 3.X version. You are correct about if I gave access to whole dataset in bigquery then users can see schema for whole thing but we want to give granular access to the tables here.
Comment From: codenamelxl
Thank you for fixing this issue. I am sorry but description clearly mentions my issue. Tagging different issue with this issue here is wrong. This feature got lost in past upgrades. I remember this was working correctly in 3.X version. You are correct about if I gave access to whole dataset in bigquery then users can see schema for whole thing but we want to give granular access to the tables here.
AFAIK, there is no table level control on this part of SQL_Lab. It's only up until schema(database) level. If you want to enforce table level control, you will have to do it on your underlying Datasource (not superset).
Or you can try creating a Dataset and control from there. But I rmb vaguely that it does not apply to SQL Lab
Comment From: Hen0k
I am also facing this issue in Postgres. It was working with 4.1.2. After moving to 5.0.0 it stopped working. I was controlling the access using superset roles and creating datasets with the tables. These roles allow me to give granular permission to the data. And I don't want to give access to an entire schema or the whole database.
Comment From: ts-saurabhkdm
@rusackas As @Hen0k mentioned. This is the issue.
Comment From: Hen0k
@rusackas , @betodealmeida I started testing this from 3.0.0 upto 4.1.0 and 4.1.0 is where this feature stops working. I made sure to drop the metadata schema that superset was using to start from a clean metadata database.
I think it is related to the removal of sl_tables or something related. The API call from the frontend is consistent, but on 4.1.0 the response it gets is an empty list. I saw a few merges related to changes on the semantic layer of dataset handling.
I hope this helps move things faster. I am stuck in a situation where I either give my users permission to an entire schema or downgrade to 4.0.0. And I am not even sure downgrading will work without metadata loss.
Comment From: Hen0k
@rusackas @michael-s-molina Could this PR have had something to do with this issue?
And a small update on when the feature stops. I was able to confirm it working on 4.0.2 and it stops working on 4.1.0
Any feedback is much appreciated.