apache/superset · error
User does not have permission to update the theme
Error message
User does not have permission to update the theme
What it means
ThemeController.validateThemeUpdatePermission throws when canSetTheme() is false — i.e. the current principal is not allowed to change the theme configuration. It is the guard called before any setTheme* mutation, so calling those methods as a user/extension without theme permission always fails here.
Source
Thrown at superset-frontend/src/theme/ThemeController.ts:861
// Dark mode is valid if we have a dark theme
return !!this.darkTheme;
case ThemeMode.DEFAULT:
// Default mode is valid if we have a default theme
return !!this.defaultTheme;
case ThemeMode.SYSTEM:
// System mode is valid if dark mode is available
return !!this.darkTheme;
default:
return true;
}
}
/**
* Validates permission to update theme.
*/
private validateThemeUpdatePermission(): void {
if (!this.canSetTheme())
throw new Error('User does not have permission to update the theme');
}
/**
* Validates permission to update mode.
* @throws {Error} If the user does not have permission to update the theme mode
*/
private validateModeUpdatePermission(): void {
// Check if user can set a new theme mode (dark theme must exist)
if (!this.canSetMode())
throw new Error(
'Theme mode changes are not allowed when only one theme is available',
);
}
/**
* Applies the current theme configuration to the global theme.
* This method sets the theme on the globalTheme and applies it to the Theme.
* It also handles any errors that may occur during the application of the theme.View on GitHub (pinned to f4587218dd)
Solutions
- Grant the user/role the theme-management permission (or run as a role that has it) before calling setTheme*.
- Guard the call: if (!themeController.canSetTheme()) skip or show an explanatory message.
- In embedded setups, only send setThemeConfig when the guest token grants theme capabilities.
- Catch this error at the boundary (e.g. embedded setThemeConfig method) and return a structured failure to the host.
Example fix
// before
themeController.setThemeConfig(newConfig);
// after
if (!themeController.canSetTheme()) {
addDangerToast(t('You do not have permission to change the theme'));
return;
}
themeController.setThemeConfig(newConfig); Defensive patterns
Strategy: validation
Validate before calling
if (!themeController.canSetTheme()) {
// hide/disable theme controls instead of calling setTheme*
return;
}
themeController.setThemeConfig(config); Try / catch
try {
themeController.setThemeConfig(config);
} catch (e) {
if (e instanceof Error && e.message.includes('permission')) {
addDangerToast(t('You cannot change the theme'));
return;
}
throw e;
} Prevention
- Gate theme UI behind canSetTheme() so unauthorized users never trigger the throw.
- In embedded hosts, check guest capabilities before sending setThemeConfig/setThemeMode.
- Keep theme permission grants aligned with the roles that own theming.
When it happens
Trigger: Calling themeController.setThemeConfig / setTheme while the running user lacks the theme-management permission (canSetTheme() false); embedded guest or restricted role invoking a theme API; programmatic theming from a plugin without checking permission first.
Common situations: Custom roles without the theme capability; embedded dashboards where the host app pushes setThemeConfig over the Switchboard but the guest session cannot set themes; permission changes after rollout of themed dashboards.
Related errors
- Cannot convert node type: ${node.type}
- Theme mode changes are not allowed when only one theme is av
- User doesn't have permission to create or update datasets
- Dashboard doesn't exist and user doesn't have permission to
- Database doesn't exist and user doesn't have permission to c
AI-assisted analysis of apache/superset@f4587218dd (2026-08-14).
Data as JSON: /api/errors/1e6e0fb33b9a7297.
Report an issue: GitHub.