docs: cut 6.1.0 versions for user_docs, admin_docs, developer_docs, components

Snapshots all four versioned Docusaurus sections at v6.1.0, cut from
master after the version-cutting tooling (#39837), broken-internal-
links fix (#40102), and user_docs rename (#40171) all landed. With
the rename in place, all four sections now produce parallel-named
files at the docs/ root (no more bare `versioned_docs/` outlier).

Versioning behavior: lastVersion stays at current for every section,
so the canonical URLs (/user-docs/..., /admin-docs/...,
/developer-docs/..., /components/...) continue to render content
from master. The current version is consistently labeled "Next"
with an unreleased banner, and 6.1.0 is a historical pin accessible
only via its explicit version segment.

Component playground: previously disabled: true in versions-config.json,
now enabled and versioned.

Snapshot includes:
- All MDX content for the four sections.
- Auto-gen captured fresh: 74 database pages (engine spec metadata),
  ~1,800 API reference files (openapi.json), 59 component pages
  (Storybook stories).
- Data imports frozen at cut time into snapshot-local _versioned_data/
  dirs:
    user_docs_versioned_docs/version-6.1.0/_versioned_data/src/data/databases.json
      (canonical 80-database diagnostics from master, preserved by the
      generator's input-hash cache)
    admin_docs_versioned_docs/version-6.1.0/_versioned_data/data/countries.json
    admin_docs_versioned_docs/version-6.1.0/_versioned_data/static/feature-flags.json
    developer_docs_versioned_docs/version-6.1.0/_versioned_data/static/data/components.json
- Import paths in deeply-nested files rewritten so they still resolve
  from one directory deeper inside the snapshot.
- developer_docs/extensions/overview.md snapshot has the FIXED
  ./mcp.md form (from #40102), so the SPA-nav 404 isn't baked into
  the 6.1.0 version.

Verified via full yarn build: exit 0, no broken links surfaced by
onBrokenLinks: throw.
This commit is contained in:
Claude Code
2026-05-15 22:36:30 -07:00
parent 8a86ab7319
commit 4ee42fe5b8
2045 changed files with 88217 additions and 6 deletions

View File

@@ -0,0 +1,78 @@
---
title: Granular Export Controls
sidebar_position: 4
---
# Granular Export Controls
Superset provides granular, permission-based controls for data export, image export, and clipboard operations. These replace the legacy `can_csv` permission with three fine-grained permissions that can be assigned independently to roles.
## Feature Flag
Granular export controls are gated behind the `GRANULAR_EXPORT_CONTROLS` feature flag. When the flag is disabled, the legacy `can_csv` permission behavior is preserved.
```python
FEATURE_FLAGS = {
"GRANULAR_EXPORT_CONTROLS": True,
}
```
## Permissions
| Permission | Resource | Controls |
| -------------------- | ---------- | ---------------------------------------------------------------------- |
| `can_export_data` | `Superset` | CSV, Excel, and JSON data exports from charts, dashboards, and SQL Lab |
| `can_export_image` | `Superset` | Screenshot (JPEG/PNG) and PDF exports from charts and dashboards |
| `can_copy_clipboard` | `Superset` | Copy-to-clipboard operations in SQL Lab and the Explore data pane |
## Default Role Assignments
The migration grants all three new permissions (`can_export_data`, `can_export_image`, `can_copy_clipboard`) to every role that currently has `can_csv`. This preserves existing behavior — no role loses access during the upgrade.
After the migration, admins can selectively revoke individual export permissions from any role to restrict access. For example, to prevent Gamma users from exporting data or images while still allowing clipboard operations, revoke `can_export_data` and `can_export_image` from the Gamma role.
## Configuration Steps
1. **Enable the feature flag** in `superset_config.py`:
```python
FEATURE_FLAGS = {
"GRANULAR_EXPORT_CONTROLS": True,
}
```
2. **Run the database migration** to register the new permissions:
```bash
superset db upgrade
```
3. **Initialize permissions** so roles are populated:
```bash
superset init
```
4. **Verify role assignments** in **Settings > List Roles**. Confirm that each role has the expected permissions from the table above.
5. **Customize as needed**: Grant or revoke individual export permissions on any role through the role editor.
## User Experience
When a user lacks a required export permission:
- **Menu items** (CSV, Excel, JSON, screenshot) appear **disabled** with an info tooltip icon explaining the restriction
- **Buttons** (SQL Lab download, clipboard copy) appear **disabled** with a tooltip on hover
- **API endpoints** return **403 Forbidden** when the corresponding permission is missing
## API Enforcement
The following API endpoints enforce granular export permissions when the feature flag is enabled:
| Endpoint | Required Permission |
| --------------------------------------------------------- | ------------------- |
| `GET /api/v1/chart/{id}/data/` (CSV/Excel format) | `can_export_data` |
| `GET /api/v1/chart/{id}/cache_screenshot/` | `can_export_image` |
| `POST /api/v1/dashboard/{id}/cache_dashboard_screenshot/` | `can_export_image` |
| `GET /api/v1/sqllab/export/{client_id}/` | `can_export_data` |
| `POST /api/v1/sqllab/export_streaming/` | `can_export_data` |