Dashboard Color Scheme#

Overview#

Dashboard color schemes in Apache Superset control how categorical colors are assigned across all charts on a dashboard. Color settings live at two levels: dashboard-level (in json_metadata) and chart-level (in each slice's params column). The dashboard-level settings take precedence over chart-level settings during rendering.

Storage#

Dashboard-level (json_metadata)#

The Dashboard model stores all color-related metadata in its json_metadata column. The following keys are written and normalized by DashboardDAO.set_dash_metadata:

A dedicated update_colors_config method provides a targeted update path for just these five color keys without touching other metadata.

The frontend TypeScript type for these fields is defined in DashboardInfo.metadata.

Chart-level (slice params)#

Each Slice model stores chart config in a params column 1, exposed as the form_data property. A chart's color_scheme field inside params is the chart's own color scheme, carried through the rendering pipeline as own_color_scheme.

Color Scheme Fallback & Application#

Fallback hierarchy#

When a chart is opened in Explore from a dashboard context, getFormDataWithDashboardContext resolves the effective color scheme:

dashboardColorScheme || ownColorScheme → applied color_scheme

• If the dashboard has a color_scheme set, it wins.
• If not, the chart's own color_scheme (from its params) is used.
• own_color_scheme is always preserved in form data alongside dashboard_color_scheme so the chart's individual setting is never discarded.

Explore chart hydration#

In hydrateExplore, a verifyColorScheme check runs on startup. If the chart's saved color_scheme no longer exists in the scheme registry, it falls back to the registry's default — supersetColors for categorical charts, superset_seq_1 for sequential.

Dashboard rendering pipeline#

Color info flows through three stages when rendering charts inside a dashboard:

1. On load — DashboardContainer calls applyDashboardLabelsColorOnLoad(dashboardInfo.metadata) to seed stored colors into the CategoricalColorNamespace.

2. Per-chart form data merge — getFormDataWithExtraFilters merges dashboard-level color fields (label_colors, map_label_colors, shared_label_colors, color_scheme) into each chart's form data on every render. The chart's own scheme is passed as own_color_scheme. Results are memoized per chart to avoid unnecessary re-renders 2.

3. Color namespace isolation — applyColors orchestrates actual color assignment into the CategoricalColorNamespace. The color_namespace key creates a per-dashboard namespace instance so multiple open dashboards don't bleed colors into each other 3. getColorNamespace normalizes falsy values to undefined to fall back to the global namespace.

Label color synchronization#

shared_label_colors tracks which labels appear in more than one chart. map_label_colors is the full persisted color map. Custom per-label overrides in label_colors are applied last 4 and always win over scheme-derived colors. SyncDashboardState writes all color context to localStorage under DashboardExploreContext 5, making it available to Explore when launched from within a dashboard tab.

Editing Color Schemes#

• Properties Modal (PUT /api/v1/dashboard/{id}): The color scheme picker is rendered via ColorSchemeControlWrapper, which imports applyColors and getColorNamespace from src/utils/colorScheme 6 and calls them immediately on submit before the server responds.
• Direct JSON editing: The Properties Modal's Advanced section exposes the raw json_metadata editor for programmatic field manipulation 7.

Key Files#