Permission Propagation#

Superset's permission system flows through four distinct layers: backend role definitions → bootstrap data serialization → frontend Redux state → UI component visibility. Understanding the handoff between each layer is critical for debugging missing menu items, adding new capability checks, or modifying role behavior.

1. Backend: Role Definitions and Capability Checks#

Permissions are modeled as PermissionView (PVM) records — a composite of a Permission (action, e.g. can_read) and a ViewMenu (resource, e.g. Dashboard). All PVM lifecycle is managed by SupersetSecurityManager in superset/security/manager.py, which extends Flask-AppBuilder's SecurityManager. 1

Built-in roles (Admin, Alpha, Gamma, sql_lab) are rebuilt on every superset init via sync_role_definitions(). Custom object-scoped permissions (datasource_access, schema_access, database_access) are never assigned to built-in roles — they are managed per-object via SQLAlchemy event hooks. 1

Runtime resource access enforcement happens in raise_for_access(), which checks ownership, guest tokens, dashboard roles (if DASHBOARD_RBAC is on), and datasource access — in that order. 2

2. Backend → Frontend: Bootstrap Serialization#

On every page load, render_app_template() in BaseSupersetView calls bootstrap_user_data(g.user, include_perms=True) and embeds the result as JSON in the HTML template.

bootstrap_user_data calls get_permissions(user), which:

1. Calls FAB's get_user_roles_permissions(user) to get a role_name → [[perm, view], ...] mapping across all of the user's roles.
2. Separately extracts datasource_access and database_access tuples into a flat permissions dict.

The resulting bootstrap payload shape is typed on the frontend as UserWithPermissionsAndRoles:

roles: Record<string, [string, string][]> // role → [[action, view], ...]
permissions: { database_access?: string[], datasource_access?: string[] }

3. Frontend Redux State: Hydration#

The user slice of Redux state is populated from the bootstrap data at app startup. For the dashboard page specifically, hydrateDashboard reads state.user.roles and derives several computed permission booleans that are stored in dashboardInfo 3:

canUserEditDashboard requires isUserAdmin || isUserDashboardOwner and can_write on Dashboard. canUserSaveAsDashboard adds conditional logic for the DASHBOARD_RBAC feature flag.

4. Core Utility: findPermission#

findPermission(perm, view, roles) is the canonical frontend primitive for permission checking. It is memoized with memoizeOne and scans Object.values(roles) for any [perm_, view_] tuple matching the given (perm, view) pair. 4

5. UI Component Visibility#

Dashboard chart menu (SliceHeaderControls): The usePermissions hook calls findPermission against state.user.roles via useSelector to derive booleans for chart-level actions 5:

SliceHeaderControls consumes these values to conditionally render menu items such as "Edit chart", "View query", "View as table", "Download", and "Share". 6

Dashboard header menu: canEditCrossFilters is read from dashboardInfo.dash_edit_perm in Redux directly via useSelector. 7 The dashboard header kebab menu also gates items like "Embed dashboard" (userCanCurate) and "Share" (userCanShare) from dashboardInfo flags set during hydration. 8

Flow Diagram#

Key Source Files#