Download button visible for users with only can read permissions (v4.1.2)

[sukisevensuki-jpg]

In Apache Superset v4.1.2, users who are granted strictly read-only permissions (can read on Chart, can read on Dashboard) still see and can use the "Download" functionality (Image, PDF) from the dashboard menu.
From a security governance perspective, we expect to be able to restrict data export capabilities separately from data

Grant the following permissions to this role:
can read on Chart
can read on Dashboard
can dashboard on Superset
datasource access on [Database].[Table]

[dosubot[bot]]

This is expected behavior in Superset v4.1.2 — there's currently no separate permission to control download/export access on dashboards. If a user can view the dashboard, they can export it.

The Download menu has no permission-based visibility controls, and the backend screenshot endpoints only check for dashboard read access.

Workarounds:

• CSS hiding (cosmetic only, not secure): You can hide the menu items via custom CSS, but users could still call the export endpoints directly
• Embedded SDK: For embedded dashboards, use guest tokens with a custom read-only role

A feature request for role-based control to hide the Download menu has been raised but isn't implemented yet. You may want to add your use case there to help prioritize it.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[sukisevensuki-jpg]

"All or Nothing" Problem: Global CSS hides the download button for everyone, including Admins and Data Owners who legitimately need to export data for reporting or auditing. We cannot afford to disable functionality for privileged users just to restrict it for others.@dosubot

[dosubot[bot]]

You're right — that's the core limitation with the CSS workaround. Superset doesn't expose user role information in the DOM, so there's no way to write role-conditional CSS that hides elements only for specific users.

Unfortunately, there's no built-in solution for this today. The download functionality is tied to dashboard read access with no separate permission to control it. This is exactly the gap that the feature request for role-based Download menu control aims to address.

For a real solution, you'd likely need a custom frontend modification that:

1. Exposes the user's role information to the DOM (e.g., as a data-role attribute)
2. Uses that to conditionally render the Download menu

This would require forking or extending the Superset frontend code. If this is a blocker for your organization, adding your use case and requirements to the existing feature request could help prioritize native support.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[manimovassagh]

Beyond the CSS workaround Dosu mentioned (which is visual-only), you can actually enforce this server-side using FLASK_APP_MUTATOR in your superset_config.py:

def mutate_app(app):
    from flask import g, request, abort

    @app.before_request
    def block_dashboard_export():
        # Block screenshot/thumbnail/export endpoints for non-admin roles
        export_paths = [
            '/api/v1/dashboard/export',
            '/api/v1/chart/export',
        ]
        screenshot_patterns = ['/thumbnail/', '/screenshot/']

        path = request.path
        if any(path.startswith(p) for p in export_paths) or \
           any(p in path for p in screenshot_patterns):
            if hasattr(g, 'user') and g.user and not g.user.has_role('Admin'):
                abort(403)

    return app

FLASK_APP_MUTATOR = mutate_app

Combine this with the CSS approach to also hide the buttons in the UI:

/* Add via Dashboard CSS or a custom Jinja template */
.header-actions-container [data-test="download-dropdown"] {
  display: none;
}

This gives you both visual removal and backend enforcement. The before_request hook runs before any view function, so even if someone crafts a direct API call, they'll get a 403.

For a cleaner long-term solution, it would be great to see a native can export on Dashboard permission added to FAB. That's the right architectural approach -- the frontend would check the permission and conditionally render the download menu, while the backend would enforce it on the API endpoints.