Scalable way to customize Superset for UX improvisation

[georgeteena]

Hi,

Since we started using Superset (currently v6.0.0), we received some feedback on dashboard level filters (e.g. auto-apply filter selection without the apply button).
I read about developers customising the community version. What's a scalable and least painful way to do this, while keeping up to date with Superset's latest stable versions? Note - we are not going for a look and feel overhaul. Our goal is mostly functional and utilitarian.

Thanks!
@dosu

[dosubot[bot]]

Great question! Here's a practical breakdown of how to customize Superset scalably while staying upgradeable:

Prioritize these customization methods (in order of maintainability):

1. Configuration overrides via superset_config.py — Create your own config file and set it via SUPERSET_CONFIG_PATH. Only override the settings you need; Superset imports your file at the end of its core config [1]. This survives upgrades cleanly.

2. Feature flags — Toggle functionality on/off without code changes. Set them in your superset_config.py under FEATURE_FLAGS dict [2].

3. Visualization plugins — For custom chart types, build standalone plugins using the ChartPlugin class. This has explicit backward-compatibility guarantees—breaking changes only happen in major releases [3].

4. CSS customization — For styling tweaks, use dashboard-level CSS to target specific elements without touching core code [2].

Regarding auto-apply filters: Unfortunately, there's currently no built-in feature flag or configuration to remove the "Apply" button and auto-apply filter selections. This is a known community request — maintainers have acknowledged it "differs from most BI tools and UX expectations," but it hasn't been implemented yet. Your options are:

• URL parameters — Pre-apply filters when loading dashboards via the native_filters URL parameter (rison-encoded), useful for linked navigation [4]
• Frontend modification — Modify the FilterBar component's handleApply logic to auto-dispatch [5], but this means maintaining a fork of frontend code, which is the least scalable path

For staying current across upgrades:

• Superset follows semantic versioning with a structured deprecation process — deprecated features get a feature flag first, then removal only in major releases [3]
• Keep customizations isolated to superset_config.py and standalone plugins
• Test upgrades in staging, paying special attention to major version bumps
• Avoid modifying core frontend/backend code directly — anything not in a plugin or config file will create merge conflicts on every upgrade

For your specific use case (functional/utilitarian changes, not visual overhaul), I'd recommend staying on the config + feature flags path for everything possible, and tracking upstream issues like the auto-apply filter request to avoid maintaining custom patches longer than necessary.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[georgeteena]

@dosu,
I am using feature flags and superset_config.py for customisations. But we need to do one or two UX improvements.

Frontend modification — Modify the FilterBar component's handleApply logic to auto-dispatch #37069, but this means maintaining a fork of frontend code, which is the least scalable path

anything not in a plugin or config file will create merge conflicts on every upgrade

This is what I noticed as well. Keeping the fork updated is difficult with all the merge conflicts, and build steps fail. There are 1000s of forks today, so I wonder how these forks are maintained and or updated.

[dosubot[bot]]

You're hitting the core tension — Superset's frontend extensibility for behavioral changes (not just charts or styling) is genuinely limited right now. Here's the honest picture:

Why most forks struggle: The community consensus is that most of those 1000s of forks are either (a) not kept up to date, (b) pinned to a specific version, or (c) maintaining only very shallow patches. Direct frontend source modifications create merge conflicts on every upgrade, and there's no general-purpose component override or hook system to avoid this [1].

What's actually available without forking:

• Extensions Registry — lets you inject custom React components at a few specific points (welcome.banner, welcome.message, navbar.right), but it doesn't cover FilterBar behavior [2]
• FLASK_APP_MUTATOR — powerful for backend logic injection via superset_config.py, but doesn't help with frontend UX [1] [3]
• CSS/theming — good for visual tweaks, not behavioral changes [4]

For auto-apply filters specifically: This is a recognized extensibility gap. The "Apply" button behavior was intentional but is being reconsidered based on community feedback [5]. There's no configuration path to change it today.

If you must patch frontend code, some strategies to minimize pain:

1. Keep patches minimal and isolated — touch as few files as possible, ideally only the specific component logic (e.g., the FilterBar apply handler)
2. Use git rebase workflow — rebase your branch on upstream tags rather than merging; this surfaces conflicts early and keeps history clean
3. Pin to stable release tags — don't track master; upgrade deliberately between tagged releases
4. Separate your changes into atomic commits — makes it easier to re-apply patches after resolving conflicts
5. Track upstream issues — the auto-apply filter request (#37069) may eventually land upstream, eliminating the need for your patch

A potentially cleaner alternative for filters: There's a community-discussed approach of building custom filter components as custom charts using native cross-filtering [6]. This removes you from the FilterBar code entirely and places filter controls anywhere on the dashboard canvas — worth exploring if it fits your UX goals.

The reality is that for one or two targeted behavioral changes, a thin fork with minimal, well-isolated patches is what most teams end up doing. It's not ideal, but it's manageable if you treat those patches as temporary until upstream catches up.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[FrancescoCastaldi]

The most scalable way to customize Superset without falling into maintenance debt or painful merge conflicts on every upstream release is to use extension points and configuration layers rather than forking the core frontend codebase.

Here is the recommended hierarchy of customizations, ordered from least maintenance to most:

1. Configuration & Feature Flags (superset_config.py)

Many UX behaviors (including dashboard filters) are configurable out of the box:

• Auto-apply native filters without the Apply button: In native filter configuration, check "Auto-apply filter changes on selection" or configure DASHBOARD_NATIVE_FILTERS: True with default auto-apply behavior.
• Theme Variables: Superset 6.x supports Ant Design theme token overrides through THEME_OVERRIDES in superset_config.py, allowing you to adjust brand colors, corner radius, padding, and font sizes across all pages without rebuilding assets.

2. Dashboard Custom CSS (Zero Maintenance on Upgrade)

For utilitarian UX adjustments (such as hiding specific buttons, adjusting card margins, or highlighting active tabs):

• Use Edit Dashboard -> Edit CSS.
• CSS rules live in the Superset metadata database rather than container source code. They persist seamlessly across version upgrades.

3. Dynamic Plugins for Custom Visualizations (SIP-38)

If you need custom chart controls or tables:

• Never edit plugins inside superset-frontend/plugins/.
• Build your custom plugin as a separate npm package using @superset-ui/generator-superset.
• Set DYNAMIC_PLUGINS = True in superset_config.py and register the plugin at runtime via URL or an administrative script.

4. Docker Multi-Stage Asset Overlay (If you must patch files)

If a functional requirement strictly necessitates modifying a core frontend file (e.g., FilterBar.tsx):

• Maintain your changes as isolated .patch files or discrete source files in your deployment git repository.
• Use a multi-stage Dockerfile that builds from the official release tag:

FROM apache/superset:6.1.0 AS custom
COPY ./patches/FilterBar.tsx /app/superset-frontend/src/dashboard/components/nativeFilters/FilterBar/FilterBar.tsx
# Rebuild only the frontend bundle layer

This keeps your base image pinned to official security releases while keeping your customizations transparent and easily rebased.