color_scheme always back to supersetColors when chart is exported

[faqirilmu31]

Hi everyone, i'm not sure if anybody has asked it before (but I can't find any exact topic)..

But i found that every time I export any chart, the color_scheme always goes back to the default, supersetColors, even though I've updated the chart to airbnb or rainbow or otherwise.

[dosubot[bot]]

Hi @faqirilmu31! I'm Dosu and I'm helping the Apache Superset team.

This is expected behavior due to how Superset's architecture handles color schemes. The color_scheme setting is stored as dashboard-level metadata (in dashboard.json_metadata) rather than in the individual chart's params or query_context fields [1]. When you export a chart, only the chart's own fields (params, query_context, slice_name, etc.) are serialized [2], so the color scheme is not included in the export.

When the exported chart is loaded without its original dashboard context, Superset's hydration logic detects the missing color scheme and falls back to the default 'supersetColors' [3].

Workarounds:

• Export the entire dashboard instead of individual charts — dashboard export includes json_metadata with the color_scheme setting.
• Manually set the color scheme in the destination dashboard properties after importing charts.

If you believe color_scheme should be persisted at the chart level as well, that would be a feature request / enhancement to the chart export logic.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dosubot[bot]]

Good catch, @faqirilmu31 — you're right, and I need to correct my earlier response. color_scheme is part of the chart's params JSON field, and the export code does not strip or filter it out. The ExportChartsCommand exports params as-is, only removing a few top-level metadata keys like datasource_type and url_params [1]. Similarly, the import code doesn't reset color_scheme either [2].

So the question becomes: why is it reverting for you? A few possibilities:

1. The color scheme was never saved in the chart's params to begin with. If the color was only set at the dashboard level (via dashboard json_metadata), the chart's own params may not contain color_scheme at all. When it's missing, the frontend falls back to supersetColors. You can verify this by checking the exported YAML file — look for color_scheme inside the params block and see if it's actually there.

2. Dashboard color metadata override. There's a reported issue where dashboard-level color settings (shared_label_colors, map_label_colors) override chart-level color schemes. Even if the chart has the correct color_scheme in params, the dashboard metadata can take precedence after import.

Regarding your dashboard export only showing 1 of 3 charts: the export logic does include all charts from the dashboard's slice list and even appends "orphan" charts referenced in the layout position [3]. However, there's a potential issue in the import logic — a break statement when processing chart UUIDs could stop processing remaining charts if a UUID match isn't found [4]. Could you check:

• Does the exported ZIP file contain all 3 chart YAML files under the charts/ folder?
• If yes, the issue is on the import side. If not, something is going wrong during export.

This would help narrow down whether the problem is with export or import.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[faqirilmu31]

Ohh i see @dosu, so can i say that color_scheme, show_legend, metric, etc. are part of the JSON field, right? Where can i get the list of if? Coz metrics is in params, but I don't think it's a JSON field, it supposed to be part that has to update.

When i export the dashboard, it only shows me 1 chart; the 2 left didn't get extracted. How ya?

[dosubot[bot]]

@faqirilmu31, yes — color_scheme, show_legend, metric, metrics, and all other visualization-specific settings are stored inside the params JSON blob, not as separate database columns [1]. The Slice model only has a handful of actual database columns like slice_name, viz_type, params, query_context, datasource_id, cache_timeout, etc. [2]. Everything else — all the chart configuration — lives inside params as a JSON string.

Unfortunately, there is no single definitive list of what keys go inside params. The structure is dynamic and depends on the chart type (viz_type). Each chart plugin defines its own set of controls, and the resulting form data all gets serialized into params. The structure has also evolved over time through various migrations [3] [4]. The best way to see what's in there for a given chart is to export it and look at the params block in the YAML file.

---

Regarding your 2 missing charts on dashboard export: the export logic pulls charts from the dashboard_slices association table via model.slices [5] [6]. If only 1 chart is exported, the other 2 are likely not linked in dashboard_slices even though they appear on the dashboard UI (via position_json).

To debug this, you can run:

SELECT * FROM dashboard_slices WHERE dashboard_id = <your_dashboard_id>;

If you see only 1 row instead of 3, that confirms the issue — the other charts aren't properly associated. Removing and re-adding them to the dashboard via the UI should fix it.

Also worth noting: there's a caching issue where the export endpoint can serve stale ZIPs from browser cache. Try exporting in incognito mode or clearing your cache to rule that out.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[faqirilmu31]

Okay @dosu, can i say that actually we can't do the development-production phase for the chart visualisation? And how about other charts (for the metrics, dimensions, etc), will they change?

Where can i run this query SELECT * FROM dashboard_slices WHERE dashboard_id = <your_dashboard_id>; ? I've tried to export-import multiple times, but the result is still the same; only 1 chart is extracted

[dosubot[bot]]

@faqirilmu31, to answer your questions:

Can you use export/import as a dev-to-production workflow?

You can, but it's not a perfect 1:1 copy. Here's what's preserved and what's not:

• ✅ Preserved: metrics, dimensions (groupby), color_scheme, show_legend, and other chart controls inside params — these survive export/import as-is [1] [2].
• ✅ Preserved: slice_name, viz_type, cache_timeout, query_context [3].
• ⚠️ Rewritten: Datasource references are remapped to match the target environment's database/dataset IDs [2].
• ❌ Stripped: EVENT/INTERVAL annotation layers are dropped — only FORMULA annotations survive [1].
• ❌ Not included in chart export: Dashboard-level color settings (shared_label_colors, map_label_colors) — these only come along with a full dashboard export [4].

So your metrics and dimensions should not change during export/import. If color_scheme is saved in the chart's params, it should also be preserved.

---

Where to run the SQL query?

The dashboard_slices table is in Superset's metadata database — this is the database configured via SQLALCHEMY_DATABASE_URI in your Superset config [5]. It's typically PostgreSQL, MySQL, or SQLite depending on your setup. You'd connect to it directly using a database client (psql, mysql, sqlite3, DBeaver, etc.) — not through SQL Lab, which is meant for querying your analytics data sources [6].

If you don't have direct database access, there's an API alternative:

GET /api/v1/dashboard/<dashboard_id_or_slug>/charts

This returns all charts associated with your dashboard [7] [8]. You can hit this from your browser or with curl. If the response only shows 1 chart, that confirms the other 2 aren't properly linked in the database, and you'd need to remove and re-add them to the dashboard via the UI to fix the association.

---

About your export still showing only 1 chart: since you've tried multiple times with the same result, also try clearing your browser cache or using incognito mode — there's a known caching issue where the export endpoint can serve stale ZIP files. If that doesn't help, use the API above to confirm how many charts are actually linked to your dashboard.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.