Hey @Mayeu! 👋

There are a few similar discussions related to issues with the DASHBOARD_RBAC feature in Apache Superset:

1. Issue with Dashboard Access for Role-Based Permissions (DASHBOARD_RBAC=True) - This discussion is unsolved and might provide insights into similar problems ^[1].

2. Non-admin user cannot see Edit Dashboard button, even on dashboards they own - This is another unsolved discussion that might be related to role-based access issues ^[2].

3. A closed issue, RBAC not Working, was resolved by a pull request that fixed the use of normal RBAC when no roles were chosen ^[3].

Regarding your specific issue, the error message indicates that the user lacks the necessary datasource or all_datasource_access permission. When DASHBOARD_RBAC is enabled, users with the Gamma role need explicit datasource_access permissions for the datasets associated with the dashboard. You can add this permission by modifying the role's permissions in the security manager ^[4].

Additionally, ensure that the DASHBOARD_RBAC feature is correctly configured in your superset_config.py file, and that the roles are properly assigned to both the user and the dashboard ^[5].

To continue talking to Dosu, mention @dosu.

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

Allowing myself to poke direct members of this repository (@villebro, @amitmiran137, @geido), because this bot answer is not useful. I know all those tickets, I have read them, and one of them is just a poor user fighting against that bot.

Please deactivate issue responses from that bot. Auto-labelling is fine, but on most issues I saw here the bot seems to just add noise and confuse users.

From the error it seems the gamma user does not have access to the data source the dashboard is deriving it's data from? Have you give the gamma user permission to access the data source as well? or only assigned the dashboard to the gamma role?

From the error it seems the gamma user does not have access to the data source the dashboard is deriving it's data from?

Correct, that's what DASHBOARD_RBAC is for, see the documentation: https://superset.apache.org/docs/using-superset/creating-your-first-dashboard/#manage-access-to-dashboards

• Granting a role access to a dashboard will bypass dataset level checks. Having dashboard access implicitly grants read access to all the featured charts in the dashboard, and thereby also all the associated datasets.

As this issue demonstrates, enabling DASHBOARD_RBAC and granting a role access to a dashboard does not bypass dataset level checks, so that's a bug.

I always CC @dpgaspar when RBAC bugs come up 🤞

DASHBOARD_RBAC may not work for datasets included via dataset() Jinja template macro

If anyone works on this one, I kindly request please making sure that the case is tested too in which the dataset needed by the dashboard contains a Jinja snippet that includes another dataset as a subquery using the dataset() macro (e.g., SELECT * FROM {{ dataset(42) }}) [0].

• To be clear, this Jinja dataset inclusion is a feature fairly separate from DASHBOARD_RBAC and does work fine to nest/generate queries.
• However the point of this comment is that it is important to make sure that DASHBOARD_RBAC does let the users (given role based dashboard access) to access the dataset expanded by the Jinja dataset() macro as well; the "nested" dataset(s) need to be accessible, too.

The reason for this comment comment is that, while the dataset() macro expands successfully, I have recently had to specifically grant dataset access to a Role getting denied dataset that was the nested/Jinja-included dataset used within the dataset of a chart, even though DASHBOARD_RBAC was enabled and was anticipated to have allowed access already, according to the docs, since "Granting a role access to a dashboard will bypass dataset level checks."

I'm not 100% sure if it's the same issue bug tracked in this Issue, but it seems like it could be, so I point it out in case there is something there, to be included in testing/bugfixing, please.

Thank you for the great Superset dashboarding software.

[0] https://superset.apache.org/docs/configuration/sql-templating/

I ran into the same problem. In my case, the code in the security manager expects a field named dashboardId, which was missing in the formData object.

Instead, the dashboards field is both included in the schema and actually sent by the frontend, making it more relevant to me. As a result, the check:

and (dashboard_id := form_data.get("dashboardId"))

always evaluated to False—so the logic for DASHBOARD_RBAC never got a chance to run. Patching the code to handle the actual field name (or list of IDs) fixed the issue.

Hope this can help.

Seems like there was something removed that handled casing differences between the row level security config and the security check on charts in the dashboard. We discovered that if we changed the casing of the table, view, or virtual dataset in the query that the charts were built upon (such that the casing matched the RBAC entry), then it would work.