cccs-tom opened a new issue #19360: URL: https://github.com/apache/superset/issues/19360
In our deployment, we have a "sandbox" database where analysts are free to create and delete schemas and tables at will. In order to support this, we assign them a role that includes the 'can write on Dataset', 'menu access on Upload a CSV' and 'database access on [sandbox]' permissions. The database connection itself is configured to 'Allow DML' and 'Allow data upload'. When a user who has been assigned that roles creates a dataset against a table in that database, they are then unable to see their dataset listed under Datasets. It also does not appear in the drop-down on the Chart creation dialog. #### How to reproduce the bug 1. Configure a 'sandbox' Database as described, i.e. Expose the database in SQL Lab, Allow DML and allow it to be explored. Also (under Security) allow data to be uploaded 2. Configure a role with 'can write on Dataset', 'menu access on Upload a CSV' and 'database access on [sandbox]' permissions 3. Create a user and assign them the Gamma role as well as the role created in step 2 4. With the new user, create a Dataset in the sandbox database - it can be on an existing table, but I did most of my testing using 'Upload a CSV'. It doesn't seem to matter whether the dataset is physical or virtual. 5. Once the dataset is successfully created, go to Data -> Datasets or the Chart creation dialog and try to find it in the list 6. Using an Admin user, you should be able to confirm that the dataset was indeed created ### Expected results I would expect any user who has been assigned the same role (and thus, has database-level permission) to be able to see the dataset and create a chart that uses it. Or at the very least, I would expect the creator and any Owner of the dataset to see their dataset. ### Actual results * The dataset is invisible to the creator / Owners and any user who doesn't have the 'all datasource access on all_datasource_access' permission. * However, the dataset **is not fully inaccessible**. If the user is provided with a direct link (e.g. https://company.com/superset/explore/table/{id}/), then they are able to explore the dataset and run queries against it. Upon debugging this with @villebro, it looks like there are multiple code paths to determine what datasets a user can see and they are inconsistent with each other. ### Environment - browser type and version: Doesn't seem to matter, but I have tested with Firefox 91 and Chrome 99. - superset version: 1.4.0 - python version: 3.8.12 - any feature flags active: - "ENABLE_TEMPLATE_PROCESSING": True, - "DASHBOARD_NATIVE_FILTERS": True, - "DASHBOARD_CROSS_FILTERS": True, - "DASHBOARD_NATIVE_FILTERS_SET": True, - "DASHBOARD_RBAC": True, - "ENABLE_EXPLORE_DRAG_AND_DROP": False, - "ENABLE_TEMPLATE_REMOVE_FILTERS": True, ### Checklist - [x] I have checked the superset logs for python stacktraces and included it here as text if there are any. - [x] I have reproduced the issue with at least the latest released version of superset. - [x] I have checked the issue tracker for the same issue and I haven't found one similar. ### Additional context * One work-around we have found for this issue is to add a schema-level permission to the users' role. Unfortunately, this doesn't really scale well since, as mentioned, our analysts are free to create and delete schemas in this database. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
