Hi,
We are attempting to create a highly restricted user in Caravel. This user can create slices and dashboards, but only for a specific set of datasources. They should not be able to even see the existence of other datasource when creating a slice.
We currently have two datasources, one as an admin datasource with access to everything, and one as a restricted datasource for the restricted user.
When navigating to the Slice, the restricted user can still see all of the other datasources, even if restriction is denied.
Is there a way to prevent the restricted user from even seeing the other datasources?

(Sorry for duplicating this question in the Google Group.)
Thank you!
Is the restricted user member of the gamma or alpha group?
Confirmed as bug, we show all the datasources without filtering the one the user has access to.
The user is a part of a new role, called Client that is based on Alpha. It has a more limited set of permissions than Alpha, which I have attached to this ticket for reference.
permissions.txt
Work in progress fix here:
https://github.com/xrmx/caravel/commit/bd078b52988753fd2bb061f63026c804583feceb
I need to sort out how to fix the tests because the user is getting redirected to the request access view:
@jasonshah could you please confirm is this bug fixed or not?
As I can see the proposed fix has been merged into the master branch
https://github.com/airbnb/superset/pull/1489
But the ticket still open
And I faced the same issue
I just retested this on 0.17.0.
It somewhat works. When exploring the slice, the restricted user is shown the Datasource field, but it is empty and the spinner is constantly spinning. So, it "works" but it's certainly not clean.

@jasonshah thank you
it would be nice to see the permissions of the restricted role. Could you please share the role permissions?
because my restricted user has permission only on 1 datasource, but he can see all datasources
We then set up a separate role for each of our clients, e.g. client_name. This role has permissions:
[datasource access on [Warehouse - client_name].full_views]
where Warehouse - client_name is a separate datasource that points to a separate client-specific login for the Postgres database for that client. We'd have one of these datasources for each client.
We then create a user for that client, and give the the roles of Client and client_name .
We haven't actually rolled this to any production clients yet, unfortunately, because of the issue in this ticket and in 1498. But hopefully soon.
Notice: this issue has been closed because it has been inactive for 389 days. Feel free to comment and request for this issue to be reopened.
I am facing the same issue with superset v 0.25.6. The issue still persists as the user seeing all the datasources in chart drop down that he has no access to. I have given user the gamma role and new role that only has permission to a single datasource
@mistercrunch this issue still exists... all databases are passed back to the SQL editor whether the user has role permission or not.
PR for this issue. https://github.com/apache/incubator-superset/pull/6356
Same issue in superset 0.27.0 version. Is there a way to prevent the restricted user from seeing the other data sources in sqllab
Most helpful comment
[can this form post on ResetMyPasswordView, can this form get on ResetMyPasswordView, can this form post on UserInfoEditView, can this form get on UserInfoEditView, menu access on List Users, menu access on List Roles, can chart on UserStatsChartView, menu access on User's Statistics, can list on PermissionModelView, menu access on Base Permissions, can list on ViewMenuModelView, menu access on Views/Menus, can list on PermissionViewModelView, menu access on Permission on Views/Menus, can list on TableColumnInlineView, can show on TableColumnInlineView, can list on SqlMetricInlineView, can show on SqlMetricInlineView, menu access on Import Dashboards, menu access on Sources, can list on TableModelView, can show on TableModelView, menu access on Tables, menu access on Access requests, can list on SliceModelView, can show on SliceModelView, can add on SliceModelView, menu access on Slices, can list on SliceAsync, can show on SliceAsync, can list on SliceAddView, can show on SliceAddView, can list on DashboardModelView, can show on DashboardModelView, mulexport on DashboardModelView, menu access on Dashboards, can list on DashboardModelViewAsync, can show on DashboardModelViewAsync, mulexport on DashboardModelViewAsync, can list on LogModelView, can show on LogModelView, menu access on Action Log, can extra table metadata on Superset, can queries on Superset, can add slices on Superset, can checkbox on Superset, can testconn on Superset, can explore json on Superset, can save dash on Superset, can results on Superset, can explore on Superset, can table on Superset, can sql json on Superset, can dashboard on Superset, can search queries on Superset, can warm up cache on Superset, can cached key on Superset, can activity per day on Superset, can csv on Superset, can tables on Superset, can slice on Superset, can request access on Superset, menu access on Query Search, can created slices on Superset]
We then set up a separate role for each of our clients, e.g. client_name. This role has permissions:
[datasource access on [Warehouse - client_name].full_views]
where Warehouse - client_name is a separate datasource that points to a separate client-specific login for the Postgres database for that client. We'd have one of these datasources for each client.
We then create a user for that client, and give the the roles of Client and client_name .
We haven't actually rolled this to any production clients yet, unfortunately, because of the issue in this ticket and in 1498. But hopefully soon.