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

  1. Grant the user/role the theme-management permission (or run as a role that has it) before calling setTheme*.
  2. Guard the call: if (!themeController.canSetTheme()) skip or show an explanatory message.
  3. In embedded setups, only send setThemeConfig when the guest token grants theme capabilities.
  4. 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

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


AI-assisted analysis of apache/superset@f4587218dd (2026-08-14). Data as JSON: /api/errors/1e6e0fb33b9a7297. Report an issue: GitHub.