You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by "NicoMovh (via GitHub)" <gi...@apache.org> on 2026/07/02 12:02:27 UTC
[D] Allow assigning a Group to a dashboard's access list [superset]
GitHub user NicoMovh created a discussion: Allow assigning a Group to a dashboard's access list
With user Groups now in superset, it's still not possible to grant a *group* access to a dashboard. Dashboard access remains role-only.
For SSO deployments where team membership is expressed as groups (LDAP/OIDC), this means you can't share a dashboard with a group without a stand-in role per group which reintroduces exactly the per-role overhead that groups were meant to remove.
Could the group → dashboard binding be delivered mirroring the existing role mechanism? Adding a `dashboard_groups` association parallel to `dashboard_roles` with the `DASHBOARD_RBAC` flag.
This is really just the "Viewer" slice of the Subject model that was already
designed in [#28021](https://github.com/apache/superset/issues/28021) (SIP-126, now closed) and re-proposed in the [#32116](https://github.com/apache/superset/issues/32116) (SIP-156, closed too) thread where a dashboard's access list would accept a User, Group, or Role, and DASHBOARD_RBAC roles would be migrated into Viewers. Rather than waiting on that full Subject/Viewer migration (now under [#28377](https://github.com/apache/superset/issues/28377, SIP-131), could just the Group-as-Viewer part land incrementally on top of the groups that already shipped?
This Discussion is asking specifically whether the dashboard-group case can be delivered on top of
the groups that is already available, rather than waiting on a full redesign.
GitHub link: https://github.com/apache/superset/discussions/41684
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Allow assigning a Group to a dashboard's access list [superset]
Posted by "NicoMovh (via GitHub)" <gi...@apache.org>.
GitHub user NicoMovh edited a discussion: Allow assigning a Group to a dashboard's access list
Hello,
With user Groups now in superset, it's still not possible to grant a *group* access to a dashboard. Dashboard access remains role-only.
For SSO deployments where team membership is expressed as groups (LDAP/OIDC), this means you can't share a dashboard with a group without a stand-in role per group which reintroduces exactly the per-role overhead that groups were meant to remove.
The workaround is to have 1 role for each group which seems against why groups where made in the first place.
Could the group → dashboard binding be delivered mirroring the existing role mechanism? Adding a `dashboard_groups` association parallel to `dashboard_roles` with the `DASHBOARD_RBAC` flag.
This is really just the "Viewer" slice of the Subject model that was already
designed in [#28021](https://github.com/apache/superset/issues/28021) (SIP-126, now closed) and re-proposed in the [#32116](https://github.com/apache/superset/issues/32116) (SIP-156, closed too) thread where a dashboard's access list would accept a User, Group, or Role, and DASHBOARD_RBAC roles would be migrated into Viewers. Rather than waiting on that full Subject/Viewer migration (now under [#28377](https://github.com/apache/superset/issues/28377, SIP-131), could just the Group-as-Viewer part land incrementally on top of the groups that already shipped?
This Discussion is asking specifically whether the dashboard-group case can be delivered on top of
the groups that is already available, rather than waiting on a full redesign.
GitHub link: https://github.com/apache/superset/discussions/41684
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Allow assigning a Group to a dashboard's access list [superset]
Posted by "NicoMovh (via GitHub)" <gi...@apache.org>.
GitHub user NicoMovh edited a discussion: Allow assigning a Group to a dashboard's access list
Hello,
With user Groups now in superset, it's still not possible to grant a *group* access to a dashboard. Dashboard access remains role-only.
For SSO deployments where team membership is expressed as groups (LDAP/OIDC), this means you can't share a dashboard with a group without a stand-in role per group which reintroduces exactly the per-role overhead that groups were meant to remove.
Could the group → dashboard binding be delivered mirroring the existing role mechanism? Adding a `dashboard_groups` association parallel to `dashboard_roles` with the `DASHBOARD_RBAC` flag.
This is really just the "Viewer" slice of the Subject model that was already
designed in [#28021](https://github.com/apache/superset/issues/28021) (SIP-126, now closed) and re-proposed in the [#32116](https://github.com/apache/superset/issues/32116) (SIP-156, closed too) thread where a dashboard's access list would accept a User, Group, or Role, and DASHBOARD_RBAC roles would be migrated into Viewers. Rather than waiting on that full Subject/Viewer migration (now under [#28377](https://github.com/apache/superset/issues/28377, SIP-131), could just the Group-as-Viewer part land incrementally on top of the groups that already shipped?
This Discussion is asking specifically whether the dashboard-group case can be delivered on top of
the groups that is already available, rather than waiting on a full redesign.
GitHub link: https://github.com/apache/superset/discussions/41684
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Allow assigning a Group to a dashboard's access list [superset]
Posted by "NicoMovh (via GitHub)" <gi...@apache.org>.
GitHub user NicoMovh edited a discussion: Allow assigning a Group to a dashboard's access list
Hello,
With user Groups now in superset, it's still not possible to grant a *group* access to a dashboard. Dashboard access remains role-only.
For SSO deployments where team membership is expressed as groups (LDAP/OIDC), this means you can't share a dashboard with a group without a stand-in role per group which reintroduces exactly the per-role overhead that groups were meant to remove.
Could the group → dashboard binding be delivered mirroring the existing role mechanism? Adding a `dashboard_groups` association parallel to `dashboard_roles` with the `DASHBOARD_RBAC` flag.
This is really just the "Viewer" slice of the Subject model that was already
designed in [#28021](https://github.com/apache/superset/issues/28021) (SIP-126, now closed) and re-proposed in the [#32116](https://github.com/apache/superset/issues/32116) (SIP-156, closed too) thread where a dashboard's access list would accept a User, Group, or Role, and DASHBOARD_RBAC roles would be migrated into Viewers. Rather than waiting on that full Subject/Viewer migration (now under [#28377](https://github.com/apache/superset/issues/28377, SIP-131), could just the Group-as-Viewer part land incrementally on top of the groups that already shipped?
This Discussion is asking specifically whether the dashboard-group case can be delivered on top of
the groups that is already available, rather than waiting on a full redesign.
GitHub link: https://github.com/apache/superset/discussions/41684
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
Re: [D] Allow assigning a Group to a dashboard's access list [superset]
Posted by "NicoMovh (via GitHub)" <gi...@apache.org>.
GitHub user NicoMovh edited a discussion: Allow assigning a Group to a dashboard's access list
Hello,
With user Groups now in superset, it's still not possible to grant a *group* access to a dashboard. Dashboard access remains role-only.
For SSO deployments where team membership is expressed as groups (LDAP/OIDC), this means you can't share a dashboard with a group without a stand-in role per group which reintroduces exactly the per-role overhead that groups were meant to remove.
Could the group → dashboard binding be delivered mirroring the existing role mechanism? Adding a `dashboard_groups` association parallel to `dashboard_roles` with the `DASHBOARD_RBAC` flag.
This is really just the "Viewer" slice of the Subject model that was already designed in [#28021](https://github.com/apache/superset/issues/28021) (SIP-126, now closed) and re-proposed in the [#32116](https://github.com/apache/superset/issues/32116) (SIP-156, closed too) thread where a dashboard's access list would accept a User, Group, or Role, and DASHBOARD_RBAC roles would be migrated into Viewers. Rather than waiting on that full Subject/Viewer migration (now under [#28377](https://github.com/apache/superset/issues/28377, SIP-131), could just the Group-as-Viewer part land incrementally on top of the groups that already shipped?
This Discussion is asking specifically whether the dashboard-group case can be delivered on top of
the groups that is already available, rather than waiting on a full redesign.
GitHub link: https://github.com/apache/superset/discussions/41684
----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org