Fix tests

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Beto Dealmeida <roberto@dealmeida.net>

.devcontainer/Dockerfile

@@ -0,0 +1,20 @@
+# Keep this in sync with the base image in the main Dockerfile (ARG PY_VER)
+FROM python:3.11.13-bookworm AS base
+
+# Install system dependencies that Superset needs
+# This layer will be cached across Codespace sessions
+RUN apt-get update && apt-get install -y \
+    libsasl2-dev \
+    libldap2-dev \
+    libpq-dev \
+    tmux \
+    gh \
+    && rm -rf /var/lib/apt/lists/*
+
+# Install uv for fast Python package management
+# This will also be cached in the image
+RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
+    echo 'export PATH="/root/.cargo/bin:$PATH"' >> /etc/bash.bashrc
+
+# Set the cargo/bin directory in PATH for all users
+ENV PATH="/root/.cargo/bin:${PATH}"

.devcontainer/README.md

@@ -0,0 +1,16 @@
+# Superset Development with GitHub Codespaces
+
+For complete documentation on using GitHub Codespaces with Apache Superset, please see:
+
+**[Setting up a Development Environment - GitHub Codespaces](https://superset.apache.org/docs/contributing/development#github-codespaces-cloud-development)**
+
+## Pre-installed Development Environment
+
+When you create a new Codespace from this repository, it automatically:
+
+1. **Creates a Python virtual environment** using `uv venv`
+2. **Installs all development dependencies** via `uv pip install -r requirements/development.txt`
+3. **Sets up pre-commit hooks** with `pre-commit install`
+4. **Activates the virtual environment** automatically in all terminals
+
+The virtual environment is located at `/workspaces/{repository-name}/.venv` and is automatically activated through environment variables set in the devcontainer configuration.

.devcontainer/bashrc-additions

@@ -0,0 +1,62 @@
+# Superset Codespaces environment setup
+# This file is appended to ~/.bashrc during Codespace setup
+
+# Find the workspace directory (handles both 'superset' and 'superset-2' names)
+WORKSPACE_DIR=$(find /workspaces -maxdepth 1 -name "superset*" -type d | head -1)
+
+if [ -n "$WORKSPACE_DIR" ]; then
+    # Check if virtual environment exists
+    if [ -d "$WORKSPACE_DIR/.venv" ]; then
+        # Activate the virtual environment
+        source "$WORKSPACE_DIR/.venv/bin/activate"
+        echo "✅ Python virtual environment activated"
+
+        # Verify pre-commit is installed and set up
+        if command -v pre-commit &> /dev/null; then
+            echo "✅ pre-commit is available ($(pre-commit --version))"
+            # Install git hooks if not already installed
+            if [ -d "$WORKSPACE_DIR/.git" ] && [ ! -f "$WORKSPACE_DIR/.git/hooks/pre-commit" ]; then
+                echo "🪝 Installing pre-commit hooks..."
+                cd "$WORKSPACE_DIR" && pre-commit install
+            fi
+        else
+            echo "⚠️  pre-commit not found. Run: pip install pre-commit"
+        fi
+    else
+        echo "⚠️  Python virtual environment not found at $WORKSPACE_DIR/.venv"
+        echo "   Run: cd $WORKSPACE_DIR && .devcontainer/setup-dev.sh"
+    fi
+
+    # Always cd to the workspace directory for convenience
+    cd "$WORKSPACE_DIR"
+fi
+
+# Add helpful aliases for Superset development
+alias start-superset="$WORKSPACE_DIR/.devcontainer/start-superset.sh"
+alias setup-dev="$WORKSPACE_DIR/.devcontainer/setup-dev.sh"
+
+# Show helpful message on login
+echo ""
+echo "🚀 Superset Codespaces Environment"
+echo "=================================="
+
+# Check if Superset is running
+if docker ps 2>/dev/null | grep -q "superset"; then
+    echo "✅ Superset is running!"
+    echo "   - Check the 'Ports' tab for your live Superset URL"
+    echo "   - Initial startup takes 10-20 minutes"
+    echo "   - Login: admin/admin"
+else
+    echo "⚠️  Superset is not running. Use: start-superset"
+    # Check if there's a startup log
+    if [ -f "/tmp/superset-startup.log" ]; then
+        echo "   📋 Startup log found: cat /tmp/superset-startup.log"
+    fi
+fi
+
+echo ""
+echo "Quick commands:"
+echo "  start-superset - Start Superset with Docker Compose"
+echo "  setup-dev      - Set up Python environment (if not already done)"
+echo "  pre-commit run - Run pre-commit checks on staged files"
+echo ""

.devcontainer/build-and-push-image.sh

@@ -0,0 +1,20 @@
+#!/bin/bash
+# Script to build and push the devcontainer image to GitHub Container Registry
+# This allows caching the image between Codespace sessions
+
+# You'll need to run this with appropriate GitHub permissions
+# gh auth login --scopes write:packages
+
+REGISTRY="ghcr.io"
+OWNER="apache"
+REPO="superset"
+TAG="devcontainer-base"
+
+echo "Building devcontainer image..."
+docker build -t $REGISTRY/$OWNER/$REPO:$TAG .devcontainer/
+
+echo "Pushing to GitHub Container Registry..."
+docker push $REGISTRY/$OWNER/$REPO:$TAG
+
+echo "Done! Update .devcontainer/devcontainer.json to use:"
+echo "  \"image\": \"$REGISTRY/$OWNER/$REPO:$TAG\""

.devcontainer/devcontainer.json

@@ -0,0 +1,66 @@
+{
+  "name": "Apache Superset Development",
+  // Option 1: Use pre-built image directly
+  // "image": "ghcr.io/apache/superset:devcontainer-base",
+
+  // Option 2: Build from Dockerfile with cache (current approach)
+  "build": {
+    "dockerfile": "Dockerfile",
+    "context": ".",
+    // Cache from the Apache registry image
+    "cacheFrom": ["ghcr.io/apache/superset:devcontainer-base"]
+  },
+
+  "features": {
+    "ghcr.io/devcontainers/features/docker-in-docker:2": {
+      "moby": true,
+      "dockerDashComposeVersion": "v2"
+    },
+    "ghcr.io/devcontainers/features/node:1": {
+      "version": "20"
+    },
+    "ghcr.io/devcontainers/features/git:1": {},
+    "ghcr.io/devcontainers/features/common-utils:2": {
+      "configureZshAsDefaultShell": true
+    },
+    "ghcr.io/devcontainers/features/sshd:1": {
+      "version": "latest"
+    }
+  },
+
+  // Forward ports for development
+  "forwardPorts": [9001],
+  "portsAttributes": {
+    "9001": {
+      "label": "Superset (via Webpack Dev Server)",
+      "onAutoForward": "notify",
+      "visibility": "public"
+    }
+  },
+
+  // Run commands after container is created
+  "postCreateCommand": "bash .devcontainer/setup-dev.sh || echo '⚠️ Setup had issues - run .devcontainer/setup-dev.sh manually'",
+
+  // Auto-start Superset after ensuring Docker is ready
+  // Run in foreground to see any errors, but don't block on failures
+  "postStartCommand": "bash -c 'echo \"Waiting 30s for services to initialize...\"; sleep 30; .devcontainer/start-superset.sh || echo \"⚠️ Auto-start failed - run start-superset manually\"'",
+
+  // Set environment variables
+  "remoteEnv": {
+    // Removed automatic venv activation to prevent startup issues
+    // The setup script will handle this
+  },
+
+  // VS Code customizations
+  "customizations": {
+    "vscode": {
+      "extensions": [
+        "ms-python.python",
+        "ms-python.vscode-pylance",
+        "charliermarsh.ruff",
+        "dbaeumer.vscode-eslint",
+        "esbenp.prettier-vscode"
+      ]
+    }
+  }
+}

.devcontainer/setup-dev.sh

@@ -0,0 +1,78 @@
+#!/bin/bash
+# Setup script for Superset Codespaces development environment
+
+echo "🔧 Setting up Superset development environment..."
+
+# System dependencies and uv are now pre-installed in the Docker image
+# This speeds up Codespace creation significantly!
+
+# Create virtual environment using uv
+echo "🐍 Creating Python virtual environment..."
+if ! uv venv; then
+    echo "❌ Failed to create virtual environment"
+    exit 1
+fi
+
+# Install Python dependencies
+echo "📦 Installing Python dependencies..."
+if ! uv pip install -r requirements/development.txt; then
+    echo "❌ Failed to install Python dependencies"
+    echo "💡 You may need to run this manually after the Codespace starts"
+    exit 1
+fi
+
+# Install pre-commit hooks
+echo "🪝 Installing pre-commit hooks..."
+if source .venv/bin/activate && pre-commit install; then
+    echo "✅ Pre-commit hooks installed"
+else
+    echo "⚠️  Pre-commit hooks installation failed (non-critical)"
+fi
+
+# Install Claude Code CLI via npm
+echo "🤖 Installing Claude Code..."
+if npm install -g @anthropic-ai/claude-code; then
+    echo "✅ Claude Code installed"
+else
+    echo "⚠️  Claude Code installation failed (non-critical)"
+fi
+
+# Make the start script executable
+chmod +x .devcontainer/start-superset.sh
+
+# Add bashrc additions for automatic venv activation
+echo "🔧 Setting up automatic environment activation..."
+if [ -f ~/.bashrc ]; then
+    # Check if we've already added our additions
+    if ! grep -q "Superset Codespaces environment setup" ~/.bashrc; then
+        echo "" >> ~/.bashrc
+        cat .devcontainer/bashrc-additions >> ~/.bashrc
+        echo "✅ Added automatic venv activation to ~/.bashrc"
+    else
+        echo "✅ Bashrc additions already present"
+    fi
+else
+    # Create bashrc if it doesn't exist
+    cat .devcontainer/bashrc-additions > ~/.bashrc
+    echo "✅ Created ~/.bashrc with automatic venv activation"
+fi
+
+# Also add to zshrc since that's the default shell
+if [ -f ~/.zshrc ] || [ -n "$ZSH_VERSION" ]; then
+    if ! grep -q "Superset Codespaces environment setup" ~/.zshrc; then
+        echo "" >> ~/.zshrc
+        cat .devcontainer/bashrc-additions >> ~/.zshrc
+        echo "✅ Added automatic venv activation to ~/.zshrc"
+    fi
+fi
+
+echo "✅ Development environment setup complete!"
+echo ""
+echo "📝 The virtual environment will be automatically activated in new terminals"
+echo ""
+echo "🔄 To activate in this terminal, run:"
+echo "   source ~/.bashrc"
+echo ""
+echo "🚀 To start Superset:"
+echo "   start-superset"
+echo ""

.devcontainer/start-superset.sh

@@ -0,0 +1,108 @@
+#!/bin/bash
+# Startup script for Superset in Codespaces
+
+# Log to a file for debugging
+LOG_FILE="/tmp/superset-startup.log"
+echo "[$(date)] Starting Superset startup script" >> "$LOG_FILE"
+echo "[$(date)] User: $(whoami), PWD: $(pwd)" >> "$LOG_FILE"
+
+echo "🚀 Starting Superset in Codespaces..."
+echo "🌐 Frontend will be available at port 9001"
+
+# Find the workspace directory (Codespaces clones as 'superset', not 'superset-2')
+WORKSPACE_DIR=$(find /workspaces -maxdepth 1 -name "superset*" -type d | head -1)
+if [ -n "$WORKSPACE_DIR" ]; then
+    cd "$WORKSPACE_DIR"
+    echo "📁 Working in: $WORKSPACE_DIR"
+else
+    echo "📁 Using current directory: $(pwd)"
+fi
+
+# Wait for Docker to be available
+echo "⏳ Waiting for Docker to start..."
+echo "[$(date)] Waiting for Docker..." >> "$LOG_FILE"
+max_attempts=30
+attempt=0
+while ! docker info > /dev/null 2>&1; do
+    if [ $attempt -eq $max_attempts ]; then
+        echo "❌ Docker failed to start after $max_attempts attempts"
+        echo "[$(date)] Docker failed to start after $max_attempts attempts" >> "$LOG_FILE"
+        echo "🔄 Please restart the Codespace or run this script manually later"
+        exit 1
+    fi
+    echo "   Attempt $((attempt + 1))/$max_attempts..."
+    echo "[$(date)] Docker check attempt $((attempt + 1))/$max_attempts" >> "$LOG_FILE"
+    sleep 2
+    attempt=$((attempt + 1))
+done
+echo "✅ Docker is ready!"
+echo "[$(date)] Docker is ready" >> "$LOG_FILE"
+
+# Check if Superset containers are already running
+if docker ps | grep -q "superset"; then
+    echo "✅ Superset containers are already running!"
+    echo ""
+    echo "🌐 To access Superset:"
+    echo "   1. Click the 'Ports' tab at the bottom of VS Code"
+    echo "   2. Find port 9001 and click the globe icon to open"
+    echo "   3. Wait 10-20 minutes for initial startup"
+    echo ""
+    echo "📝 Login credentials: admin/admin"
+    exit 0
+fi
+
+# Clean up any existing containers
+echo "🧹 Cleaning up existing containers..."
+docker-compose -f docker-compose-light.yml down
+
+# Start services
+echo "🏗️  Starting Superset in background (daemon mode)..."
+echo ""
+
+# Start in detached mode
+docker-compose -f docker-compose-light.yml up -d
+
+echo ""
+echo "✅ Docker Compose started successfully!"
+echo ""
+echo "📋 Important information:"
+echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+echo "⏱️  Initial startup takes 10-20 minutes"
+echo "🌐 Check the 'Ports' tab for your Superset URL (port 9001)"
+echo "👤 Login: admin / admin"
+echo ""
+echo "📊 Useful commands:"
+echo "   docker-compose -f docker-compose-light.yml logs -f    # Follow logs"
+echo "   docker-compose -f docker-compose-light.yml ps         # Check status"
+echo "   docker-compose -f docker-compose-light.yml down       # Stop services"
+echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+echo ""
+echo "💤 Keeping terminal open for 60 seconds to test persistence..."
+sleep 60
+echo "✅ Test complete - check if this terminal is still visible!"
+
+# Show final status
+docker-compose -f docker-compose-light.yml ps
+EXIT_CODE=$?
+
+# If it failed, provide helpful instructions
+if [ $EXIT_CODE -ne 0 ] && [ $EXIT_CODE -ne 130 ]; then  # 130 is Ctrl+C
+    echo ""
+    echo "❌ Superset startup failed (exit code: $EXIT_CODE)"
+    echo ""
+    echo "🔄 To restart Superset, run:"
+    echo "   .devcontainer/start-superset.sh"
+    echo ""
+    echo "🔧 For troubleshooting:"
+    echo "   # View logs:"
+    echo "   docker-compose -f docker-compose-light.yml logs"
+    echo ""
+    echo "   # Clean restart (removes volumes):"
+    echo "   docker-compose -f docker-compose-light.yml down -v"
+    echo "   .devcontainer/start-superset.sh"
+    echo ""
+    echo "   # Common issues:"
+    echo "   - Network timeouts: Just retry, often transient"
+    echo "   - Port conflicts: Check 'docker ps'"
+    echo "   - Database issues: Try clean restart with -v"
+fi

.github/CODEOWNERS

@@ -2,7 +2,7 @@
 
 # https://github.com/apache/superset/issues/13351
 
-/superset/migrations/ @mistercrunch @michael-s-molina @betodealmeida @eschutho
+/superset/migrations/ @mistercrunch @michael-s-molina @betodealmeida @eschutho @sadpandajoe
 
 # Notify some committers of changes in the components
 
@@ -30,3 +30,13 @@
 
 **/*.geojson @villebro @rusackas
 /superset-frontend/plugins/legacy-plugin-chart-country-map/ @villebro @rusackas
+
+# Notify PMC members of changes to extension-related files
+
+/superset-core/ @michael-s-molina @villebro
+/superset-cli/ @michael-s-molina @villebro
+/superset/core/ @michael-s-molina @villebro
+/superset/extensions/ @michael-s-molina @villebro
+/superset-frontend/src/packages/superset-core/ @michael-s-molina @villebro
+/superset-frontend/src/core/ @michael-s-molina @villebro
+/superset-frontend/src/extensions/ @michael-s-molina @villebro

.github/actions/change-detector/action.yml

@@ -1,24 +1,27 @@
-name: 'Change Detector'
-description: 'Detects file changes for pull request and push events'
+name: Change Detector
+description: Detects file changes for pull request and push events
 inputs:
   token:
-    description: 'GitHub token for authentication'
+    description: GitHub token for authentication
     required: true
 outputs:
   python:
-    description: 'Whether Python-related files were changed'
+    description: Whether Python-related files were changed
     value: ${{ steps.change-detector.outputs.python }}
   frontend:
-    description: 'Whether frontend-related files were changed'
+    description: Whether frontend-related files were changed
     value: ${{ steps.change-detector.outputs.frontend }}
   docker:
-    description: 'Whether docker-related files were changed'
+    description: Whether docker-related files were changed
     value: ${{ steps.change-detector.outputs.docker }}
   docs:
-    description: 'Whether docs-related files were changed'
+    description: Whether docs-related files were changed
     value: ${{ steps.change-detector.outputs.docs }}
+  superset-cli:
+    description: Whether superset-cli package-related files were changed
+    value: ${{ steps.change-detector.outputs.superset-cli }}
 runs:
-  using: 'composite'
+  using: composite
   steps:
     - name: Detect file changes
       id: change-detector

.github/workflows/docker.yml

@@ -102,7 +102,7 @@ jobs:
           docker history $IMAGE_TAG
 
       - name: docker-compose sanity check
-        if: (steps.check.outputs.python || steps.check.outputs.frontend || steps.check.outputs.docker) && (matrix.build_preset == 'dev' || matrix.build_preset == 'lean')
+        if: (steps.check.outputs.python || steps.check.outputs.frontend || steps.check.outputs.docker) && matrix.build_preset == 'dev'
         shell: bash
         run: |
           export SUPERSET_BUILD_TARGET=${{ matrix.build_preset }}

.github/workflows/superset-app-cli.yml

@@ -0,0 +1,67 @@
+name: Superset App CLI tests
+
+on:
+  push:
+    branches:
+      - "master"
+      - "[0-9].[0-9]*"
+  pull_request:
+    types: [synchronize, opened, reopened, ready_for_review]
+
+# cancel previous workflow jobs for PRs
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
+  cancel-in-progress: true
+
+jobs:
+  test-load-examples:
+    runs-on: ubuntu-24.04
+    env:
+      PYTHONPATH: ${{ github.workspace }}
+      SUPERSET_CONFIG: tests.integration_tests.superset_test_config
+      REDIS_PORT: 16379
+      SUPERSET__SQLALCHEMY_DATABASE_URI: postgresql+psycopg2://superset:superset@127.0.0.1:15432/superset
+    services:
+      postgres:
+        image: postgres:16-alpine
+        env:
+          POSTGRES_USER: superset
+          POSTGRES_PASSWORD: superset
+        ports:
+          # Use custom ports for services to avoid accidentally connecting to
+          # GitHub action runner's default installations
+          - 15432:5432
+      redis:
+        image: redis:7-alpine
+        ports:
+          - 16379:6379
+    steps:
+      - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
+        uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+          submodules: recursive
+      - name: Check for file changes
+        id: check
+        uses: ./.github/actions/change-detector/
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+      - name: Setup Python
+        if: steps.check.outputs.python
+        uses: ./.github/actions/setup-backend/
+      - name: Setup Postgres
+        if: steps.check.outputs.python
+        uses: ./.github/actions/cached-dependencies
+        with:
+          run: setup-postgres
+      - name: superset init
+        if: steps.check.outputs.python
+        run: |
+          pip install -e .
+          superset db upgrade
+          superset load_test_users
+      - name: superset load_examples
+        if: steps.check.outputs.python
+        run: |
+          # load examples without test data
+          superset load_examples --load-big-data

.github/workflows/superset-cli.yml

@@ -1,4 +1,4 @@
-name: Superset CLI tests
+name: Superset CLI Package Tests
 
 on:
   push:
@@ -14,54 +14,51 @@ concurrency:
   cancel-in-progress: true
 
 jobs:
-  test-load-examples:
+  test-superset-cli-package:
     runs-on: ubuntu-24.04
-    env:
-      PYTHONPATH: ${{ github.workspace }}
-      SUPERSET_CONFIG: tests.integration_tests.superset_test_config
-      REDIS_PORT: 16379
-      SUPERSET__SQLALCHEMY_DATABASE_URI: postgresql+psycopg2://superset:superset@127.0.0.1:15432/superset
-    services:
-      postgres:
-        image: postgres:16-alpine
-        env:
-          POSTGRES_USER: superset
-          POSTGRES_PASSWORD: superset
-        ports:
-          # Use custom ports for services to avoid accidentally connecting to
-          # GitHub action runner's default installations
-          - 15432:5432
-      redis:
-        image: redis:7-alpine
-        ports:
-          - 16379:6379
+    strategy:
+      matrix:
+        python-version: ["previous", "current", "next"]
+    defaults:
+      run:
+        working-directory: superset-cli
     steps:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
         uses: actions/checkout@v4
         with:
           persist-credentials: false
           submodules: recursive
+
       - name: Check for file changes
         id: check
         uses: ./.github/actions/change-detector/
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
+
       - name: Setup Python
-        if: steps.check.outputs.python
+        if: steps.check.outputs.superset-cli
         uses: ./.github/actions/setup-backend/
-      - name: Setup Postgres
-        if: steps.check.outputs.python
-        uses: ./.github/actions/cached-dependencies
         with:
-          run: setup-postgres
-      - name: superset init
-        if: steps.check.outputs.python
+          python-version: ${{ matrix.python-version }}
+          requirements-type: dev
+
+      - name: Run pytest with coverage
+        if: steps.check.outputs.superset-cli
         run: |
-          pip install -e .
-          superset db upgrade
-          superset load_test_users
-      - name: superset load_examples
-        if: steps.check.outputs.python
-        run: |
-          # load examples without test data
-          superset load_examples --load-big-data
+          pytest --cov=superset_cli --cov-report=xml --cov-report=term-missing --cov-report=html -v --tb=short
+
+      - name: Upload coverage reports to Codecov
+        if: steps.check.outputs.superset-cli
+        uses: codecov/codecov-action@v3
+        with:
+          file: ./coverage.xml
+          flags: superset-cli
+          name: superset-cli-coverage
+          fail_ci_if_error: false
+
+      - name: Upload HTML coverage report
+        if: steps.check.outputs.superset-cli
+        uses: actions/upload-artifact@v4
+        with:
+          name: superset-cli-coverage-html
+          path: htmlcov/

.github/workflows/welcome-new-users.yml

@@ -12,7 +12,7 @@ jobs:
 
     steps:
       - name: Welcome Message
-        uses: actions/first-interaction@v1
+        uses: actions/first-interaction@v2
         continue-on-error: true
         with:
           repo-token: ${{ github.token }}

.gitignore

@@ -43,7 +43,7 @@ _modules
 _static
 build
 app.db
-apache_superset.egg-info/
+*.egg-info/
 changelog.sh
 dist
 dump.rdb
@@ -130,4 +130,7 @@ superset/static/stats/statistics.html
 
 # LLM-related
 CLAUDE.local.md
+PROJECT.md
 .aider*
+.claude_rc*
+.env.local

.pre-commit-config.yaml

@@ -23,7 +23,9 @@ repos:
     rev: v1.15.0
     hooks:
       - id: mypy
+        name: mypy (main)
         args: [--check-untyped-defs]
+        exclude: ^superset-cli/
         additional_dependencies: [
             types-simplejson,
             types-python-dateutil,
@@ -38,6 +40,10 @@ repos:
             types-paramiko,
             types-Markdown,
           ]
+      - id: mypy
+        name: mypy (superset-cli)
+        args: [--check-untyped-defs]
+        files: ^superset-cli/
   - repo: https://github.com/pre-commit/pre-commit-hooks
     rev: v5.0.0
     hooks:
@@ -54,25 +60,25 @@ repos:
         args: ["--markdown-linebreak-ext=md"]
   - repo: local
     hooks:
-    - id: eslint-frontend
-      name: eslint (frontend)
-      entry: ./scripts/eslint.sh
-      language: system
-      pass_filenames: true
-      files: ^superset-frontend/.*\.(js|jsx|ts|tsx)$
-    - id: eslint-docs
-      name: eslint (docs)
-      entry: bash -c 'cd docs && FILES=$(echo "$@" | sed "s|docs/||g") && yarn eslint --fix --ext .js,.jsx,.ts,.tsx --quiet $FILES'
-      language: system
-      pass_filenames: true
-      files: ^docs/.*\.(js|jsx|ts|tsx)$
-    - id: type-checking-frontend
-      name: Type-Checking (Frontend)
-      entry: ./scripts/check-type.js package=superset-frontend excludeDeclarationDir=cypress-base
-      language: system
-      files: ^superset-frontend\/.*\.(js|jsx|ts|tsx)$
-      exclude: ^superset-frontend/cypress-base\/
-      require_serial: true
+      - id: eslint-frontend
+        name: eslint (frontend)
+        entry: ./scripts/eslint.sh
+        language: system
+        pass_filenames: true
+        files: ^superset-frontend/.*\.(js|jsx|ts|tsx)$
+      - id: eslint-docs
+        name: eslint (docs)
+        entry: bash -c 'cd docs && FILES=$(echo "$@" | sed "s|docs/||g") && yarn eslint --fix --ext .js,.jsx,.ts,.tsx --quiet $FILES'
+        language: system
+        pass_filenames: true
+        files: ^docs/.*\.(js|jsx|ts|tsx)$
+      - id: type-checking-frontend
+        name: Type-Checking (Frontend)
+        entry: ./scripts/check-type.js package=superset-frontend excludeDeclarationDir=cypress-base
+        language: system
+        files: ^superset-frontend\/.*\.(js|jsx|ts|tsx)$
+        exclude: ^superset-frontend/cypress-base\/
+        require_serial: true
   # blacklist unsafe functions like make_url (see #19526)
   - repo: https://github.com/skorokithakis/blacklist-pre-commit-hook
     rev: e2f070289d8eddcaec0b580d3bde29437e7c8221
@@ -94,21 +100,21 @@ repos:
         args: [--fix]
   - repo: local
     hooks:
-    - id: pylint
-      name: pylint with custom Superset plugins
-      entry: bash
-      language: system
-      types: [python]
-      exclude: ^(tests/|superset/migrations/|scripts/|RELEASING/|docker/)
-      args:
-        - -c
-        - |
-          TARGET_BRANCH=${GITHUB_BASE_REF:-master}
-          git fetch origin "$TARGET_BRANCH"
-          BASE=$(git merge-base origin/"$TARGET_BRANCH" HEAD)
-          files=$(git diff --name-only --diff-filter=ACM "$BASE"..HEAD | grep '^superset/.*\.py$' || true)
-          if [ -n "$files" ]; then
-            pylint --rcfile=.pylintrc --load-plugins=superset.extensions.pylint --reports=no $files
-          else
-            echo "No Python files to lint."
-          fi
+      - id: pylint
+        name: pylint with custom Superset plugins
+        entry: bash
+        language: system
+        types: [python]
+        exclude: ^(tests/|superset/migrations/|scripts/|RELEASING/|docker/)
+        args:
+          - -c
+          - |
+            TARGET_BRANCH=${GITHUB_BASE_REF:-master}
+            git fetch origin "$TARGET_BRANCH"
+            BASE=$(git merge-base origin/"$TARGET_BRANCH" HEAD)
+            files=$(git diff --name-only --diff-filter=ACM "$BASE"..HEAD | grep '^superset/.*\.py$' || true)
+            if [ -n "$files" ]; then
+              pylint --rcfile=.pylintrc --load-plugins=superset.extensions.pylint --reports=no $files
+            else
+              echo "No Python files to lint."
+            fi

.rat-excludes

@@ -32,6 +32,8 @@ apache_superset.egg-info
 # json and csv in general cannot have comments
 .*json
 .*csv
+# jinja templates often need to be as-is
+.*j2
 # Generated doc files
 env/*
 docs/.htaccess*

Dockerfile

@@ -59,7 +59,7 @@ RUN mkdir -p /app/superset/static/assets \
 # NOTE: we mount packages and plugins as they are referenced in package.json as workspaces
 # ideally we'd COPY only their package.json. Here npm ci will be cached as long
 # as the full content of these folders don't change, yielding a decent cache reuse rate.
-# Note that's it's not possible selectively COPY of mount using blobs.
+# Note that it's not possible to selectively COPY or mount using blobs.
 RUN --mount=type=bind,source=./superset-frontend/package.json,target=./package.json \
     --mount=type=bind,source=./superset-frontend/package-lock.json,target=./package-lock.json \
     --mount=type=cache,target=/root/.cache \
@@ -74,7 +74,7 @@ RUN --mount=type=bind,source=./superset-frontend/package.json,target=./package.j
 COPY superset-frontend /app/superset-frontend
 
 ######################################################################
-# superset-node used for compile frontend assets
+# superset-node is used for compiling frontend assets
 ######################################################################
 FROM superset-node-ci AS superset-node
 
@@ -90,7 +90,7 @@ RUN --mount=type=cache,target=/root/.npm \
 # Copy translation files
 COPY superset/translations /app/superset/translations
 
-# Build the frontend if not in dev mode
+# Build translations if enabled, then cleanup localization files
 RUN if [ "$BUILD_TRANSLATIONS" = "true" ]; then \
         npm run build-translation; \
     fi; \
@@ -145,6 +145,9 @@ RUN if [ "$BUILD_TRANSLATIONS" = "true" ]; then \
 ######################################################################
 FROM python-base AS python-common
 
+# Build arg to pre-populate examples DuckDB file
+ARG LOAD_EXAMPLES_DUCKDB="false"
+
 ENV SUPERSET_HOME="/app/superset_home" \
     HOME="/app/superset_home" \
     SUPERSET_ENV="production" \
@@ -196,6 +199,18 @@ RUN /app/docker/apt-install.sh \
       libecpg-dev \
       libldap2-dev
 
+# Pre-load examples DuckDB file if requested
+RUN if [ "$LOAD_EXAMPLES_DUCKDB" = "true" ]; then \
+        mkdir -p /app/data && \
+        echo "Downloading pre-built examples.duckdb..." && \
+        curl -L -o /app/data/examples.duckdb \
+            "https://raw.githubusercontent.com/apache-superset/examples-data/master/examples.duckdb" && \
+        chown -R superset:superset /app/data; \
+    else \
+        mkdir -p /app/data && \
+        chown -R superset:superset /app/data; \
+    fi
+
 # Copy compiled things from previous stages
 COPY --from=superset-node /app/superset/static/assets superset/static/assets
 
@@ -219,6 +234,10 @@ FROM python-common AS lean
 
 # Install Python dependencies using docker/pip-install.sh
 COPY requirements/base.txt requirements/
+
+# Copy superset-core package needed for editable install in base.txt
+COPY superset-core superset-core
+
 RUN --mount=type=cache,target=${SUPERSET_HOME}/.cache/uv \
     /app/docker/pip-install.sh --requires-build-essential -r requirements/base.txt
 # Install the superset package
@@ -241,6 +260,11 @@ RUN /app/docker/apt-install.sh \
 
 # Copy development requirements and install them
 COPY requirements/*.txt requirements/
+
+# Copy local packages needed for editable installs in development.txt
+COPY superset-core superset-core
+COPY superset-cli superset-cli
+
 # Install Python dependencies using docker/pip-install.sh
 RUN --mount=type=cache,target=${SUPERSET_HOME}/.cache/uv \
     /app/docker/pip-install.sh --requires-build-essential -r requirements/development.txt
@@ -258,6 +282,15 @@ USER superset
 ######################################################################
 FROM lean AS ci
 USER root
-RUN uv pip install .[postgres]
+RUN uv pip install .[postgres,duckdb]
+USER superset
+CMD ["/app/docker/entrypoints/docker-ci.sh"]
+
+######################################################################
+# Showtime image - lean + DuckDB for examples database
+######################################################################
+FROM lean AS showtime
+USER root
+RUN uv pip install .[duckdb]
 USER superset
 CMD ["/app/docker/entrypoints/docker-ci.sh"]

LLMS.md

@@ -9,13 +9,16 @@ Apache Superset is a data visualization platform with Flask/Python backend and R
 ### Frontend Modernization
 - **NO `any` types** - Use proper TypeScript types
 - **NO JavaScript files** - Convert to TypeScript (.ts/.tsx)
-- **Use @superset-ui/core** - Don't import Ant Design directly
+- **Use @superset-ui/core** - Don't import Ant Design directly, prefer Ant Design component wrappers from @superset-ui/core/components
+- **Use antd theming tokens** - Prefer antd tokens over legacy theming tokens
+- **Avoid custom css and styles** - Follow antd best practices and avoid styling and custom CSS whenever possible
 
 ### Testing Strategy Migration
 - **Prefer unit tests** over integration tests
 - **Prefer integration tests** over Cypress end-to-end tests
 - **Cypress is last resort** - Actively moving away from Cypress
 - **Use Jest + React Testing Library** for component testing
+- **Use `test()` instead of `describe()`** - Follow [avoid nesting when testing](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing) principles
 
 ### Backend Type Safety
 - **Add type hints** - All new Python code needs proper typing

RELEASING/make_tarball.sh

@@ -32,11 +32,10 @@ else
   SUPERSET_VERSION="${1}"
   SUPERSET_RC="${2}"
   SUPERSET_PGP_FULLNAME="${3}"
+  SUPERSET_VERSION_RC="${SUPERSET_VERSION}rc${SUPERSET_RC}"
   SUPERSET_RELEASE_RC_TARBALL="apache_superset-${SUPERSET_VERSION_RC}-source.tar.gz"
 fi
 
-SUPERSET_VERSION_RC="${SUPERSET_VERSION}rc${SUPERSET_RC}"
-
 if [ -z "${SUPERSET_SVN_DEV_PATH}" ]; then
   SUPERSET_SVN_DEV_PATH="$HOME/svn/superset_dev"
 fi

RESOURCES/FEATURE_FLAGS.md

@@ -28,6 +28,7 @@ These features are considered **unfinished** and should only be used on developm
 [//]: # "PLEASE KEEP THE LIST SORTED ALPHABETICALLY"
 
 - ALERT_REPORT_TABS
+- DATE_RANGE_TIMESHIFTS_ENABLED
 - ENABLE_ADVANCED_DATA_TYPES
 - PRESTO_EXPAND_DATA
 - SHARE_QUERIES_VIA_KV_STORE

RESOURCES/STANDARD_ROLES.md

@@ -94,9 +94,9 @@ under the License.
 | can available domains on Superset                |:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|O|
 | can request access on Superset                   |:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|O|
 | can dashboard on Superset                        |:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|O|
-| can post on TableSchemaView                      |:heavy_check_mark:|:heavy_check_mark:|O|O|
-| can expanded on TableSchemaView                  |:heavy_check_mark:|:heavy_check_mark:|O|O|
-| can delete on TableSchemaView                    |:heavy_check_mark:|:heavy_check_mark:|O|O|
+| can post on TableSchemaView                      |:heavy_check_mark:|O|O|:heavy_check_mark:|
+| can expanded on TableSchemaView                  |:heavy_check_mark:|O|O|:heavy_check_mark:|
+| can delete on TableSchemaView                    |:heavy_check_mark:|O|O|:heavy_check_mark:|
 | can get on TabStateView                          |:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|
 | can post on TabStateView                         |:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|
 | can delete query on TabStateView                 |:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|:heavy_check_mark:|

UPDATING.md

@@ -23,6 +23,14 @@ This file documents any backwards-incompatible changes in Superset and
 assists people when migrating to a new version.
 
 ## Next
+- [34782](https://github.com/apache/superset/pull/34782): Dataset exports now include the dataset ID in their file name (similar to charts and dashboards). If managing assets as code, make sure to rename existing dataset YAMLs to include the ID (and avoid duplicated files).
+- [34536](https://github.com/apache/superset/pull/34536): The `ENVIRONMENT_TAG_CONFIG` color values have changed to support only Ant Design semantic colors. Update your `superset_config.py`:
+  - Change `"error.base"` to just `"error"` after this PR
+  - Change any hex color values to one of: `"success"`, `"processing"`, `"error"`, `"warning"`, `"default"`
+  - Custom colors are no longer supported to maintain consistency with Ant Design components
+- [34561](https://github.com/apache/superset/pull/34561) Added tiled screenshot functionality for Playwright-based reports to handle large dashboards more efficiently. When enabled (default: `SCREENSHOT_TILED_ENABLED = True`), dashboards with 20+ charts or height exceeding 5000px will be captured using multiple viewport-sized tiles and combined into a single image. This improves report generation performance and reliability for large dashboards.
+Note: Pillow is now a required dependency (previously optional) to support image processing for tiled screenshots.
+`thumbnails` optional dependency is now deprecated and will be removed in the next major release (7.0).
 - [33084](https://github.com/apache/superset/pull/33084) The DISALLOWED_SQL_FUNCTIONS configuration now includes additional potentially sensitive database functions across PostgreSQL, MySQL, SQLite, MS SQL Server, and ClickHouse. Existing queries using these functions may now be blocked. Review your SQL Lab queries and dashboards if you encounter "disallowed function" errors after upgrading
 - [34235](https://github.com/apache/superset/pull/34235) CSV exports now use `utf-8-sig` encoding by default to include a UTF-8 BOM, improving compatibility with Excel.
 - [34258](https://github.com/apache/superset/pull/34258) changing the default in Dockerfile to INCLUDE_CHROMIUM="false" (from "true") in the past. This ensures the `lean` layer is lean by default, and people can opt-in to the `chromium` layer by setting the build arg `INCLUDE_CHROMIUM=true`. This is a breaking change for anyone using the `lean` layer, as it will no longer include Chromium by default.
@@ -32,6 +40,7 @@ assists people when migrating to a new version.
 - [32317](https://github.com/apache/superset/pull/32317) The horizontal filter bar feature is now out of testing/beta development and its feature flag `HORIZONTAL_FILTER_BAR` has been removed.
 - [31590](https://github.com/apache/superset/pull/31590) Marks the begining of intricate work around supporting dynamic Theming, and breaks support for [THEME_OVERRIDES](https://github.com/apache/superset/blob/732de4ac7fae88e29b7f123b6cbb2d7cd411b0e4/superset/config.py#L671) in favor of a new theming system based on AntD V5. Likely this will be in disrepair until settling over the 5.x lifecycle.
 - [32432](https://github.com/apache/superset/pull/31260) Moves the List Roles FAB view to the frontend and requires `FAB_ADD_SECURITY_API` to be enabled in the configuration and `superset init` to be executed.
+- [34319](https://github.com/apache/superset/pull/34319) Drill to Detail and Drill By is now supported in Embedded mode, and also with the `DASHBOARD_RBAC` FF. If you don't want to expose these features in Embedded / `DASHBOARD_RBAC`, make sure the roles used for Embedded / `DASHBOARD_RBAC`don't have the required permissions to perform D2D actions.
 
 ## 5.0.0
 

docker-compose-light.yml

@@ -17,16 +17,47 @@
 
 # -----------------------------------------------------------------------
 # Lightweight docker-compose for running multiple Superset instances
-# This includes only essential services: database, Redis, and Superset app
+# This includes only essential services: database and Superset app (no Redis)
 #
-# IMPORTANT: To run multiple instances in parallel:
+# RUNNING SUPERSET:
+# 1. Start services: docker-compose -f docker-compose-light.yml up
+# 2. Access at: http://localhost:9001 (or NODE_PORT if specified)
+#
+# RUNNING MULTIPLE INSTANCES:
 # - Use different project names: docker-compose -p project1 -f docker-compose-light.yml up
 # - Use different NODE_PORT values: NODE_PORT=9002 docker-compose -p project2 -f docker-compose-light.yml up
 # - Volumes are isolated by project name (e.g., project1_db_home_light, project2_db_home_light)
 # - Database name is intentionally different (superset_light) to prevent accidental cross-connections
 #
-# For verbose logging during development:
-# - Set SUPERSET_LOG_LEVEL=debug in docker/.env-local for detailed Superset logs
+# RUNNING TESTS WITH PYTEST:
+# Tests run in an isolated environment with a separate test database.
+# The pytest-runner service automatically creates and initializes the test database on first use.
+#
+# Basic usage:
+#   docker-compose -f docker-compose-light.yml run --rm pytest-runner pytest tests/unit_tests/
+#
+# Run specific test file:
+#   docker-compose -f docker-compose-light.yml run --rm pytest-runner pytest tests/unit_tests/test_foo.py
+#
+# Run with pytest options:
+#   docker-compose -f docker-compose-light.yml run --rm pytest-runner pytest -v -s -x tests/
+#
+# Force reload test database and run tests (when tests are failing due to bad state):
+#   docker-compose -f docker-compose-light.yml run --rm -e FORCE_RELOAD=true pytest-runner pytest tests/
+#
+# Run any command in test environment:
+#   docker-compose -f docker-compose-light.yml run --rm pytest-runner bash
+#   docker-compose -f docker-compose-light.yml run --rm pytest-runner pytest --collect-only
+#
+# For parallel test execution with different projects:
+#   docker-compose -p project1 -f docker-compose-light.yml run --rm pytest-runner pytest tests/
+#
+# DEVELOPMENT TIPS:
+# - First test run takes ~20-30 seconds (database creation + initialization)
+# - Subsequent runs are fast (~2-3 seconds startup)
+# - Use FORCE_RELOAD=true when you need a clean test database
+# - Tests use SimpleCache instead of Redis (no Redis required)
+# - Set SUPERSET_LOG_LEVEL=debug in docker/.env-local for detailed logs
 # -----------------------------------------------------------------------
 x-superset-user: &superset-user root
 x-superset-volumes: &superset-volumes
@@ -46,6 +77,7 @@ x-common-build: &common-build
     INCLUDE_CHROMIUM: ${INCLUDE_CHROMIUM:-false}
     INCLUDE_FIREFOX: ${INCLUDE_FIREFOX:-false}
     BUILD_TRANSLATIONS: ${BUILD_TRANSLATIONS:-false}
+    LOAD_EXAMPLES_DUCKDB: ${LOAD_EXAMPLES_DUCKDB:-true}
 
 services:
   db-light:
@@ -56,13 +88,12 @@ services:
         required: false
     image: postgres:16
     restart: unless-stopped
-    # No host port mapping - only accessible within Docker network
     volumes:
       - db_home_light:/var/lib/postgresql/data
       - ./docker/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d
     environment:
-      # Override database name to avoid conflicts
       POSTGRES_DB: superset_light
+    command: postgres -c max_connections=200
 
   superset-light:
     env_file:
@@ -74,7 +105,6 @@ services:
       <<: *common-build
     command: ["/app/docker/docker-bootstrap.sh", "app"]
     restart: unless-stopped
-    # No host port mapping - accessed via webpack dev server proxy
     extra_hosts:
       - "host.docker.internal:host-gateway"
     user: *superset-user
@@ -83,15 +113,10 @@ services:
         condition: service_completed_successfully
     volumes: *superset-volumes
     environment:
-      # Override DB connection for light service
       DATABASE_HOST: db-light
       DATABASE_DB: superset_light
       POSTGRES_DB: superset_light
-      EXAMPLES_HOST: db-light
-      EXAMPLES_DB: superset_light
-      EXAMPLES_USER: superset
-      EXAMPLES_PASSWORD: superset
-      # Use light-specific config that disables Redis
+      SUPERSET__SQLALCHEMY_EXAMPLES_URI: "duckdb:////app/data/examples.duckdb"
       SUPERSET_CONFIG_PATH: /app/docker/pythonpath_dev/superset_config_docker_light.py
 
   superset-init-light:
@@ -103,21 +128,16 @@ services:
         required: true
       - path: docker/.env-local # optional override
         required: false
+    user: *superset-user
     depends_on:
       db-light:
         condition: service_started
-    user: *superset-user
     volumes: *superset-volumes
     environment:
-      # Override DB connection for light service
       DATABASE_HOST: db-light
       DATABASE_DB: superset_light
       POSTGRES_DB: superset_light
-      EXAMPLES_HOST: db-light
-      EXAMPLES_DB: superset_light
-      EXAMPLES_USER: superset
-      EXAMPLES_PASSWORD: superset
-      # Use light-specific config that disables Redis
+      SUPERSET__SQLALCHEMY_EXAMPLES_URI: "duckdb:////app/data/examples.duckdb"
       SUPERSET_CONFIG_PATH: /app/docker/pythonpath_dev/superset_config_docker_light.py
     healthcheck:
       disable: true
@@ -150,6 +170,31 @@ services:
         required: false
     volumes: *superset-volumes
 
+  pytest-runner:
+    build:
+      <<: *common-build
+    entrypoint: ["/app/docker/docker-pytest-entrypoint.sh"]
+    env_file:
+      - path: docker/.env # default
+        required: true
+      - path: docker/.env-local # optional override
+        required: false
+    profiles:
+      - test  # Only starts when --profile test is used
+    depends_on:
+      db-light:
+        condition: service_started
+    user: *superset-user
+    volumes: *superset-volumes
+    environment:
+      DATABASE_HOST: db-light
+      DATABASE_DB: test
+      POSTGRES_DB: test
+      SUPERSET__SQLALCHEMY_DATABASE_URI: postgresql+psycopg2://superset:superset@db-light:5432/test
+      SUPERSET__SQLALCHEMY_EXAMPLES_URI: "duckdb:////app/data/examples.duckdb"
+      SUPERSET_CONFIG: superset_test_config_light
+      PYTHONPATH: /app/pythonpath:/app/docker/pythonpath_dev:/app
+
 volumes:
   superset_home_light:
     external: false

docker-compose.yml

@@ -42,6 +42,7 @@ x-common-build: &common-build
     INCLUDE_CHROMIUM: ${INCLUDE_CHROMIUM:-false}
     INCLUDE_FIREFOX: ${INCLUDE_FIREFOX:-false}
     BUILD_TRANSLATIONS: ${BUILD_TRANSLATIONS:-false}
+    LOAD_EXAMPLES_DUCKDB: ${LOAD_EXAMPLES_DUCKDB:-true}
 
 services:
   nginx:
@@ -107,6 +108,8 @@ services:
       superset-init:
         condition: service_completed_successfully
     volumes: *superset-volumes
+    environment:
+      SUPERSET__SQLALCHEMY_EXAMPLES_URI: "duckdb:////app/data/examples.duckdb"
 
   superset-websocket:
     container_name: superset_websocket
@@ -158,6 +161,8 @@ services:
         condition: service_started
     user: *superset-user
     volumes: *superset-volumes
+    environment:
+      SUPERSET__SQLALCHEMY_EXAMPLES_URI: "duckdb:////app/data/examples.duckdb"
     healthcheck:
       disable: true
 

docker/docker-init.sh

@@ -69,6 +69,8 @@ echo_step "3" "Complete" "Setting up roles and perms"
 if [ "$SUPERSET_LOAD_EXAMPLES" = "yes" ]; then
     # Load some data to play with
     echo_step "4" "Starting" "Loading examples"
+
+
     # If Cypress run which consumes superset_test_config – load required data for tests
     if [ "$CYPRESS_CONFIG" == "true" ]; then
         superset load_examples --load-test-data

docker/docker-pytest-entrypoint.sh

@@ -0,0 +1,152 @@
+#!/bin/bash
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License.  You may obtain a copy of the License at
+#
+#    http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+set -e
+
+# Wait for PostgreSQL to be ready
+echo "Waiting for database to be ready..."
+for i in {1..30}; do
+  if python3 -c "
+import psycopg2
+try:
+    conn = psycopg2.connect(host='db-light', user='superset', password='superset', database='superset_light')
+    conn.close()
+    print('Database is ready!')
+except:
+    exit(1)
+" 2>/dev/null; then
+    echo "Database connection established!"
+    break
+  fi
+  echo "Waiting for database... ($i/30)"
+  if [ $i -eq 30 ]; then
+    echo "Database connection timeout after 30 seconds"
+    exit 1
+  fi
+  sleep 1
+done
+
+# Handle database setup based on FORCE_RELOAD
+if [ "${FORCE_RELOAD}" = "true" ]; then
+  echo "Force reload requested - resetting test database"
+  # Drop and recreate the test database using Python
+  python3 -c "
+import psycopg2
+from psycopg2.extensions import ISOLATION_LEVEL_AUTOCOMMIT
+
+# Connect to default database
+conn = psycopg2.connect(host='db-light', user='superset', password='superset', database='superset_light')
+conn.set_isolation_level(ISOLATION_LEVEL_AUTOCOMMIT)
+cur = conn.cursor()
+
+# Drop and recreate test database
+try:
+    cur.execute('DROP DATABASE IF EXISTS test')
+except:
+    pass
+
+cur.execute('CREATE DATABASE test')
+conn.close()
+
+# Connect to test database to create schemas
+conn = psycopg2.connect(host='db-light', user='superset', password='superset', database='test')
+conn.set_isolation_level(ISOLATION_LEVEL_AUTOCOMMIT)
+cur = conn.cursor()
+
+cur.execute('CREATE SCHEMA sqllab_test_db')
+cur.execute('CREATE SCHEMA admin_database')
+
+cur.close()
+conn.close()
+print('Test database reset successfully')
+"
+  # Use --no-reset-db since we already reset it
+  FLAGS="--no-reset-db"
+else
+  echo "Using existing test database (set FORCE_RELOAD=true to reset)"
+  FLAGS="--no-reset-db"
+
+  # Ensure test database exists using Python
+  python3 -c "
+import psycopg2
+from psycopg2.extensions import ISOLATION_LEVEL_AUTOCOMMIT
+
+# Check if test database exists
+try:
+    conn = psycopg2.connect(host='db-light', user='superset', password='superset', database='test')
+    conn.close()
+    print('Test database already exists')
+except:
+    print('Creating test database...')
+    # Connect to default database to create test database
+    conn = psycopg2.connect(host='db-light', user='superset', password='superset', database='superset_light')
+    conn.set_isolation_level(ISOLATION_LEVEL_AUTOCOMMIT)
+    cur = conn.cursor()
+
+    # Create test database
+    cur.execute('CREATE DATABASE test')
+    conn.close()
+
+    # Connect to test database to create schemas
+    conn = psycopg2.connect(host='db-light', user='superset', password='superset', database='test')
+    conn.set_isolation_level(ISOLATION_LEVEL_AUTOCOMMIT)
+    cur = conn.cursor()
+
+    cur.execute('CREATE SCHEMA IF NOT EXISTS sqllab_test_db')
+    cur.execute('CREATE SCHEMA IF NOT EXISTS admin_database')
+
+    cur.close()
+    conn.close()
+    print('Test database created successfully')
+"
+fi
+
+# Always run database migrations to ensure schema is up to date
+echo "Running database migrations..."
+cd /app
+superset db upgrade
+
+# Initialize test environment if needed
+if [ "${FORCE_RELOAD}" = "true" ] || [ ! -f "/app/superset_home/.test_initialized" ]; then
+  echo "Initializing test environment..."
+  # Run initialization commands
+  superset init
+  echo "Loading test users..."
+  superset load-test-users
+
+  # Mark as initialized
+  touch /app/superset_home/.test_initialized
+else
+  echo "Test environment already initialized (skipping init and load-test-users)"
+  echo "Tip: Use FORCE_RELOAD=true to reinitialize the test database"
+fi
+
+# Create missing scripts needed for tests
+if [ ! -f "/app/scripts/tag_latest_release.sh" ]; then
+  echo "Creating missing tag_latest_release.sh script for tests..."
+  cp /app/docker/tag_latest_release.sh /app/scripts/tag_latest_release.sh 2>/dev/null || true
+fi
+
+# Install pip module for Shillelagh compatibility (aligns with CI environment)
+echo "Installing pip module for Shillelagh compatibility..."
+uv pip install pip
+
+# If arguments provided, execute them
+if [ $# -gt 0 ]; then
+  exec "$@"
+fi

docker/entrypoints/run-server.sh

@@ -26,7 +26,7 @@ gunicorn \
     --workers ${SERVER_WORKER_AMOUNT:-1} \
     --worker-class ${SERVER_WORKER_CLASS:-gthread} \
     --threads ${SERVER_THREADS_AMOUNT:-20} \
-    --log-level "${GUNICORN_LOGLEVEL:info}" \
+    --log-level "${GUNICORN_LOGLEVEL:-info}" \
     --timeout ${GUNICORN_TIMEOUT:-60} \
     --keep-alive ${GUNICORN_KEEPALIVE:-2} \
     --max-requests ${WORKER_MAX_REQUESTS:-0} \

docker/frontend-mem-nag.sh

@@ -23,25 +23,57 @@ MIN_MEM_FREE_GB=3
 MIN_MEM_FREE_KB=$(($MIN_MEM_FREE_GB*1000000))
 
 echo_mem_warn() {
-  MEM_FREE_KB=$(awk '/MemFree/ { printf "%s \n", $2 }' /proc/meminfo)
-  MEM_FREE_GB=$(awk '/MemFree/ { printf "%s \n", $2/1024/1024 }' /proc/meminfo)
+  # Check if running in Codespaces first
+  if [[ -n "${CODESPACES}" ]]; then
+    echo "Memory available: Codespaces managed"
+    return
+  fi
 
-  if [[ "${MEM_FREE_KB}" -lt "${MIN_MEM_FREE_KB}" ]]; then
+  # Check platform and get memory accordingly
+  if [[ -f /proc/meminfo ]]; then
+    # Linux
+    if grep -q MemAvailable /proc/meminfo; then
+      MEM_AVAIL_KB=$(awk '/MemAvailable/ { printf "%s \n", $2 }' /proc/meminfo)
+      MEM_AVAIL_GB=$(awk '/MemAvailable/ { printf "%s \n", $2/1024/1024 }' /proc/meminfo)
+    else
+      MEM_AVAIL_KB=$(awk '/MemFree/ { printf "%s \n", $2 }' /proc/meminfo)
+      MEM_AVAIL_GB=$(awk '/MemFree/ { printf "%s \n", $2/1024/1024 }' /proc/meminfo)
+    fi
+  elif [[ "$(uname)" == "Darwin" ]]; then
+    # macOS - use vm_stat to get free memory
+    # vm_stat reports in pages, typically 4096 bytes per page
+    PAGE_SIZE=$(pagesize)
+    FREE_PAGES=$(vm_stat | awk '/Pages free:/ {print $3}' | tr -d '.')
+    INACTIVE_PAGES=$(vm_stat | awk '/Pages inactive:/ {print $3}' | tr -d '.')
+    # Free + inactive pages give us available memory (similar to MemAvailable on Linux)
+    AVAIL_PAGES=$((FREE_PAGES + INACTIVE_PAGES))
+    MEM_AVAIL_KB=$((AVAIL_PAGES * PAGE_SIZE / 1024))
+    MEM_AVAIL_GB=$(echo "scale=2; $MEM_AVAIL_KB / 1024 / 1024" | bc)
+  else
+    # Other platforms
+    echo "Memory available: Unable to determine"
+    return
+  fi
+
+  if [[ "${MEM_AVAIL_KB}" -lt "${MIN_MEM_FREE_KB}" ]]; then
     cat <<EOF
     ===============================================
     ========  Memory Insufficient Warning =========
     ===============================================
 
-    It looks like you only have ${MEM_FREE_GB}GB of
-    memory free. Please increase your Docker
+    It looks like you only have ${MEM_AVAIL_GB}GB of
+    memory ${MEM_TYPE}. Please increase your Docker
     resources to at least ${MIN_MEM_FREE_GB}GB
 
+    Note: During builds, available memory may be
+    temporarily low due to caching and compilation.
+
     ===============================================
     ========  Memory Insufficient Warning =========
     ===============================================
 EOF
   else
-    echo "Memory check Ok [${MEM_FREE_GB}GB free]"
+    echo "Memory available: ${MEM_AVAIL_GB} GB"
   fi
 }
 

docker/pythonpath_dev/superset_config.py

@@ -49,12 +49,18 @@ SQLALCHEMY_DATABASE_URI = (
     f"{DATABASE_HOST}:{DATABASE_PORT}/{DATABASE_DB}"
 )
 
-SQLALCHEMY_EXAMPLES_URI = (
-    f"{DATABASE_DIALECT}://"
-    f"{EXAMPLES_USER}:{EXAMPLES_PASSWORD}@"
-    f"{EXAMPLES_HOST}:{EXAMPLES_PORT}/{EXAMPLES_DB}"
+# Use environment variable if set, otherwise construct from components
+# This MUST take precedence over any other configuration
+SQLALCHEMY_EXAMPLES_URI = os.getenv(
+    "SUPERSET__SQLALCHEMY_EXAMPLES_URI",
+    (
+        f"{DATABASE_DIALECT}://"
+        f"{EXAMPLES_USER}:{EXAMPLES_PASSWORD}@"
+        f"{EXAMPLES_HOST}:{EXAMPLES_PORT}/{EXAMPLES_DB}"
+    ),
 )
 
+
 REDIS_HOST = os.getenv("REDIS_HOST", "redis")
 REDIS_PORT = os.getenv("REDIS_PORT", "6379")
 REDIS_CELERY_DB = os.getenv("REDIS_CELERY_DB", "0")

docker/pythonpath_dev/superset_test_config_light.py

@@ -0,0 +1,55 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+# Test configuration for docker-compose-light.yml - uses SimpleCache instead of Redis
+
+# Import all settings from the main test config first
+import os
+import sys
+
+# Add the tests directory to the path to import the test config
+sys.path.insert(0, os.path.join(os.path.dirname(__file__), "..", ".."))
+from tests.integration_tests.superset_test_config import *  # noqa: F403
+
+# Override Redis-based caching to use simple in-memory cache
+CACHE_CONFIG = {
+    "CACHE_TYPE": "SimpleCache",
+    "CACHE_DEFAULT_TIMEOUT": 300,
+    "CACHE_KEY_PREFIX": "superset_test_",
+}
+
+DATA_CACHE_CONFIG = {
+    **CACHE_CONFIG,
+    "CACHE_DEFAULT_TIMEOUT": 30,
+    "CACHE_KEY_PREFIX": "superset_test_data_",
+}
+
+# Keep SimpleCache for these as they're already using it
+# FILTER_STATE_CACHE_CONFIG - already SimpleCache in parent
+# EXPLORE_FORM_DATA_CACHE_CONFIG - already SimpleCache in parent
+
+# Disable Celery for lightweight testing
+CELERY_CONFIG = None
+
+# Use FileSystemCache for SQL Lab results instead of Redis
+from flask_caching.backends.filesystemcache import FileSystemCache  # noqa: E402
+
+RESULTS_BACKEND = FileSystemCache("/app/superset_home/sqllab_test")
+
+# Override WEBDRIVER_BASEURL for tests to match expected values
+WEBDRIVER_BASEURL = "http://0.0.0.0:8080/"
+WEBDRIVER_BASEURL_USER_FRIENDLY = WEBDRIVER_BASEURL

docker/tag_latest_release.sh

@@ -0,0 +1,190 @@
+#! /bin/bash
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+run_git_tag () {
+  if [[ "$DRY_RUN" == "false" ]] && [[ "$SKIP_TAG" == "false" ]]
+  then
+    git tag -a -f latest "${GITHUB_TAG_NAME}" -m "latest tag"
+    echo "${GITHUB_TAG_NAME} has been tagged 'latest'"
+  fi
+  exit 0
+}
+
+###
+# separating out git commands into functions so they can be mocked in unit tests
+###
+git_show_ref () {
+  if [[ "$TEST_ENV" == "true" ]]
+  then
+    if [[ "$GITHUB_TAG_NAME" == "does_not_exist" ]]
+        # mock return for testing only
+    then
+      echo ""
+    else
+      echo "2817aebd69dc7d199ec45d973a2079f35e5658b6 refs/tags/${GITHUB_TAG_NAME}"
+    fi
+  fi
+  result=$(git show-ref "${GITHUB_TAG_NAME}")
+  echo "${result}"
+}
+
+get_latest_tag_list () {
+  if [[ "$TEST_ENV" == "true" ]]
+  then
+    echo "(tag: 2.1.0, apache/2.1test)"
+  else
+    result=$(git show-ref --tags --dereference latest | awk '{print $2}' | xargs git show --pretty=tformat:%d -s | grep tag:)
+    echo "${result}"
+  fi
+}
+###
+
+split_string () {
+  local version="$1"
+  local delimiter="$2"
+  local components=()
+  local tmp=""
+  for (( i=0; i<${#version}; i++ )); do
+    local char="${version:$i:1}"
+    if [[ "$char" != "$delimiter" ]]; then
+      tmp="$tmp$char"
+    elif [[ -n "$tmp" ]]; then
+      components+=("$tmp")
+      tmp=""
+    fi
+  done
+  if [[ -n "$tmp" ]]; then
+    components+=("$tmp")
+  fi
+  echo "${components[@]}"
+}
+
+DRY_RUN=false
+
+# get params passed in with script when it was run
+# --dry-run is optional and returns the value of SKIP_TAG, but does not run the git tag statement
+# A tag name is required as a param. A SHA won't work. You must first tag a sha with a release number
+# and then run this script
+while [[ $# -gt 0 ]]
+do
+key="$1"
+
+case $key in
+    --dry-run)
+    DRY_RUN=true
+    shift # past value
+    ;;
+    *)    # this should be the tag name
+    GITHUB_TAG_NAME=$key
+    shift # past value
+    ;;
+esac
+done
+
+if [ -z "${GITHUB_TAG_NAME}" ]; then
+    echo "Missing tag parameter, usage: ./scripts/tag_latest_release.sh <GITHUB_TAG_NAME>"
+    echo "SKIP_TAG=true" >> $GITHUB_OUTPUT
+    exit 1
+fi
+
+if [ -z "$(git_show_ref)" ]; then
+    echo "The tag ${GITHUB_TAG_NAME} does not exist. Please use a different tag."
+    echo "SKIP_TAG=true" >> $GITHUB_OUTPUT
+    exit 0
+fi
+
+# check that this tag only contains a proper semantic version
+if ! [[ ${GITHUB_TAG_NAME} =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]
+then
+  echo "This tag ${GITHUB_TAG_NAME} is not a valid release version. Not tagging."
+  echo "SKIP_TAG=true" >> $GITHUB_OUTPUT
+  exit 1
+fi
+
+## split the current GITHUB_TAG_NAME into an array at the dot
+THIS_TAG_NAME=$(split_string "${GITHUB_TAG_NAME}" ".")
+
+# look up the 'latest' tag on git
+LATEST_TAG_LIST=$(get_latest_tag_list) || echo 'not found'
+
+# if 'latest' tag doesn't exist, then set this commit to latest
+if [[ -z "$LATEST_TAG_LIST" ]]
+then
+  echo "there are no latest tags yet, so I'm going to start by tagging this sha as the latest"
+  run_git_tag
+  exit 0
+fi
+
+# remove parenthesis and tag: from the list of tags
+LATEST_TAGS_STRINGS=$(echo "$LATEST_TAG_LIST" | sed 's/tag: \([^,]*\)/\1/g' | tr -d '()')
+
+LATEST_TAGS=$(split_string "$LATEST_TAGS_STRINGS" ",")
+TAGS=($(split_string "$LATEST_TAGS" " "))
+
+# Initialize a flag for comparison result
+compare_result=""
+
+# Iterate through the tags of the latest release
+for tag in $TAGS
+do
+  if [[ $tag == "latest" ]]; then
+    continue
+  else
+    ## extract just the version from this tag
+    LATEST_RELEASE_TAG="$tag"
+    echo "LATEST_RELEASE_TAG: ${LATEST_RELEASE_TAG}"
+
+    # check that this only contains a proper semantic version
+    if ! [[ ${LATEST_RELEASE_TAG} =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]
+    then
+      echo "'Latest' has been associated with tag ${LATEST_RELEASE_TAG} which is not a valid release version. Looking for another."
+      continue
+    fi
+    echo "The current release with the latest tag is version ${LATEST_RELEASE_TAG}"
+    # Split the version strings into arrays
+    THIS_TAG_NAME_ARRAY=($(split_string "$THIS_TAG_NAME" "."))
+    LATEST_RELEASE_TAG_ARRAY=($(split_string "$LATEST_RELEASE_TAG" "."))
+
+    # Iterate through the components of the version strings
+    for (( j=0; j<${#THIS_TAG_NAME_ARRAY[@]}; j++ )); do
+        echo "Comparing ${THIS_TAG_NAME_ARRAY[$j]} to ${LATEST_RELEASE_TAG_ARRAY[$j]}"
+        if [[ $((THIS_TAG_NAME_ARRAY[$j])) > $((LATEST_RELEASE_TAG_ARRAY[$j])) ]]; then
+            compare_result="greater"
+            break
+        elif [[ $((THIS_TAG_NAME_ARRAY[$j])) < $((LATEST_RELEASE_TAG_ARRAY[$j])) ]]; then
+            compare_result="lesser"
+            break
+        fi
+    done
+  fi
+done
+
+# Determine the result based on the comparison
+if [[ -z "$compare_result" ]]; then
+    echo "Versions are equal"
+    echo "SKIP_TAG=true" >> $GITHUB_OUTPUT
+elif [[ "$compare_result" == "greater" ]]; then
+    echo "This release tag ${GITHUB_TAG_NAME} is newer than the latest."
+    echo "SKIP_TAG=false" >> $GITHUB_OUTPUT
+    # Add other actions you want to perform for a newer version
+elif [[ "$compare_result" == "lesser" ]]; then
+    echo "This release tag ${GITHUB_TAG_NAME} is older than the latest."
+    echo "This release tag ${GITHUB_TAG_NAME} is not the latest. Not tagging."
+    # if you've gotten this far, then we don't want to run any tags in the next step
+    echo "SKIP_TAG=true" >> $GITHUB_OUTPUT
+fi

docs/README.md

@@ -21,3 +21,183 @@ This is the public documentation site for Superset, built using
 [Docusaurus 3](https://docusaurus.io/). See
 [CONTRIBUTING.md](../CONTRIBUTING.md#documentation) for documentation on
 contributing to documentation.
+
+## Version Management
+
+The Superset documentation site uses Docusaurus versioning with three independent versioned sections:
+
+- **Main Documentation** (`/docs/`) - Core Superset documentation
+- **Developer Portal** (`/developer_portal/`) - Developer guides and tutorials  
+- **Component Playground** (`/components/`) - Interactive component examples (currently disabled)
+
+Each section maintains its own version history and can be versioned independently.
+
+### Creating a New Version
+
+To create a new version for any section, use the Docusaurus version command with the appropriate plugin ID or use our automated scripts:
+
+#### Using Automated Scripts (Required)
+
+**⚠️ Important:** Always use these custom commands instead of the native Docusaurus commands. These scripts ensure that both the Docusaurus versioning system AND the `versions-config.json` file are updated correctly.
+
+```bash
+# Main Documentation
+yarn version:add:docs 1.2.0
+
+# Developer Portal
+yarn version:add:developer_portal 1.2.0
+
+# Component Playground (when enabled)
+yarn version:add:components 1.2.0
+```
+
+**Do NOT use** the native Docusaurus commands directly (`yarn docusaurus docs:version`), as they will:
+- ❌ Create version files but NOT update `versions-config.json`
+- ❌ Cause versions to not appear in dropdown menus
+- ❌ Require manual fixes to synchronize the configuration
+
+### Managing Versions
+
+#### With Automated Scripts
+The automated scripts handle all configuration updates automatically. No manual editing required!
+
+#### Manual Configuration
+If creating versions manually, you'll need to:
+
+1. **Update `versions-config.json`** (or `docusaurus.config.ts` if not using dynamic config):
+   - Add version to `onlyIncludeVersions` array
+   - Add version metadata to `versions` object
+   - Update `lastVersion` if needed
+
+2. **Files Created by Versioning**:
+   When a new version is created, Docusaurus generates:
+   - **Versioned docs folder**: `[section]_versioned_docs/version-X.X.X/`
+   - **Versioned sidebars**: `[section]_versioned_sidebars/version-X.X.X-sidebars.json`
+   - **Versions list**: `[section]_versions.json`
+
+   Note: For main docs, the prefix is omitted (e.g., `versioned_docs/` instead of `docs_versioned_docs/`)
+
+3. **Important**: After adding a version, restart the development server to see changes:
+   ```bash
+   yarn stop
+   yarn start
+   ```
+
+### Removing a Version
+
+#### Using Automated Scripts (Recommended)
+```bash
+# Main Documentation
+yarn version:remove:docs 1.0.0
+
+# Developer Portal
+yarn version:remove:developer_portal 1.0.0
+
+# Component Playground
+yarn version:remove:components 1.0.0
+```
+
+#### Manual Removal
+To manually remove a version:
+
+1. **Delete the version folder** from the appropriate location:
+   - Main docs: `versioned_docs/version-X.X.X/` (no prefix for main)
+   - Developer Portal: `developer_portal_versioned_docs/version-X.X.X/`
+   - Components: `components_versioned_docs/version-X.X.X/`
+
+2. **Delete the version metadata file**:
+   - Main docs: `versioned_sidebars/version-X.X.X-sidebars.json` (no prefix)
+   - Developer Portal: `developer_portal_versioned_sidebars/version-X.X.X-sidebars.json`
+   - Components: `components_versioned_sidebars/version-X.X.X-sidebars.json`
+
+3. **Update the versions list file**:
+   - Main docs: `versions.json`
+   - Developer Portal: `developer_portal_versions.json`
+   - Components: `components_versions.json`
+
+4. **Update configuration**:
+   - If using dynamic config: Update `versions-config.json`
+   - If using static config: Update `docusaurus.config.ts`
+
+5. **Restart the server** to see changes
+
+### Version Configuration Examples
+
+#### Main Documentation (default plugin)
+```typescript
+docs: {
+  includeCurrentVersion: true,
+  lastVersion: 'current',  // Makes /docs/ show Next version
+  onlyIncludeVersions: ['current', '1.1.0', '1.0.0'],
+  versions: {
+    current: {
+      label: 'Next',
+      path: '',  // Empty path for default routing
+      banner: 'unreleased',
+    },
+    '1.1.0': {
+      label: '1.1.0',
+      path: '1.1.0',
+      banner: 'none',
+    },
+  },
+}
+```
+
+#### Developer Portal & Components (custom plugins)
+```typescript
+{
+  id: 'developer_portal',
+  path: 'developer_portal',
+  routeBasePath: 'developer_portal',
+  includeCurrentVersion: true,
+  lastVersion: '1.1.0',  // Default version
+  onlyIncludeVersions: ['current', '1.1.0', '1.0.0'],
+  versions: {
+    current: {
+      label: 'Next',
+      path: 'next',
+      banner: 'unreleased',
+    },
+    '1.1.0': {
+      label: '1.1.0',
+      path: '1.1.0',
+      banner: 'none',
+    },
+  },
+}
+```
+
+### Best Practices
+
+1. **Version naming**: Use semantic versioning (e.g., 1.0.0, 1.1.0, 2.0.0)
+2. **Version banners**: Use `'unreleased'` for development versions, `'none'` for stable releases
+3. **Limit displayed versions**: Use `onlyIncludeVersions` to show only relevant versions
+4. **Test locally**: Always test version changes locally before deploying
+5. **Independent versioning**: Each section can have different version numbers and release cycles
+
+### Troubleshooting
+
+#### Version Not Showing After Creation
+
+If you accidentally used `yarn docusaurus docs:version` instead of `yarn version:add`:
+1. **Problem**: The version files were created but `versions-config.json` wasn't updated
+2. **Solution**: Either:
+   - Revert the changes: `git restore versions.json && rm -rf versioned_docs/ versioned_sidebars/`
+   - Then use the correct command: `yarn version:add:docs <version>`
+
+For other issues:
+- **Restart the server**: Changes to version configuration require a server restart
+- **Check config file**: Ensure `versions-config.json` includes the new version
+- **Verify files exist**: Check that versioned docs folder was created
+
+#### Broken Links in Versioned Documentation
+When creating a new version, links in the documentation are preserved as-is. Common issues:
+- **Cross-section links**: Links between sections (e.g., from developer_portal to docs) need to be version-aware
+- **Absolute vs relative paths**: Use relative paths within the same section
+- **Version-specific URLs**: Update hardcoded URLs to use version variables
+
+To fix broken links:
+1. Use `type: 'doc'` with `docId` for version-aware navigation in navbar
+2. Use relative paths within the same documentation section
+3. Test all versions after creation to identify broken links

docs/components/chart-components/bar-chart.md

@@ -0,0 +1,105 @@
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+---
+title: Bar Chart
+sidebar_position: 1
+---
+
+# Bar Chart Component
+
+The Bar Chart component is used to visualize categorical data with rectangular bars.
+
+## Props
+
+| Prop | Type | Default | Description |
+|------|------|---------|-------------|
+| `data` | `array` | `[]` | Array of data objects to visualize |
+| `width` | `number` | `800` | Width of the chart in pixels |
+| `height` | `number` | `600` | Height of the chart in pixels |
+| `xField` | `string` | - | Field name for x-axis values |
+| `yField` | `string` | - | Field name for y-axis values |
+| `colorField` | `string` | - | Field name for color encoding |
+| `colorScheme` | `string` | `'supersetColors'` | Color scheme to use |
+| `showLegend` | `boolean` | `true` | Whether to show the legend |
+| `showGrid` | `boolean` | `true` | Whether to show grid lines |
+| `labelPosition` | `string` | `'top'` | Position of bar labels: 'top', 'middle', 'bottom' |
+
+## Examples
+
+### Basic Bar Chart
+
+```jsx
+import { BarChart } from '@superset-ui/chart-components';
+
+const data = [
+  { category: 'A', value: 10 },
+  { category: 'B', value: 20 },
+  { category: 'C', value: 15 },
+  { category: 'D', value: 25 },
+];
+
+function Example() {
+  return (
+    <BarChart
+      data={data}
+      width={800}
+      height={400}
+      xField="category"
+      yField="value"
+      colorScheme="supersetColors"
+    />
+  );
+}
+```
+
+### Grouped Bar Chart
+
+```jsx
+import { BarChart } from '@superset-ui/chart-components';
+
+const data = [
+  { category: 'A', group: 'Group 1', value: 10 },
+  { category: 'A', group: 'Group 2', value: 15 },
+  { category: 'B', group: 'Group 1', value: 20 },
+  { category: 'B', group: 'Group 2', value: 25 },
+  { category: 'C', group: 'Group 1', value: 15 },
+  { category: 'C', group: 'Group 2', value: 10 },
+];
+
+function Example() {
+  return (
+    <BarChart
+      data={data}
+      width={800}
+      height={400}
+      xField="category"
+      yField="value"
+      colorField="group"
+      colorScheme="supersetColors"
+    />
+  );
+}
+```
+
+## Best Practices
+
+- Use bar charts when comparing quantities across categories
+- Sort bars by value for better readability, unless there's a natural order to the categories
+- Use consistent colors for the same categories across different charts
+- Consider using horizontal bar charts when category labels are long

docs/components/index.md

@@ -0,0 +1,59 @@
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+---
+title: Component Library
+sidebar_position: 1
+---
+
+# Superset Component Library
+
+Welcome to the Apache Superset Component Library documentation. This section provides comprehensive documentation for all the UI components, chart components, and layout components used in Superset.
+
+## What is the Component Library?
+
+The Component Library is a collection of reusable UI components that are used to build the Superset user interface. These components are designed to be consistent, accessible, and easy to use.
+
+## Component Categories
+
+The Component Library is organized into the following categories:
+
+### UI Components
+
+Basic UI components like buttons, inputs, dropdowns, and other form elements.
+
+### Chart Components
+
+Visualization components used to render different types of charts and graphs.
+
+### Layout Components
+
+Components used for page layout, such as containers, grids, and navigation elements.
+
+## Versioning
+
+The Component Library documentation follows its own versioning scheme, independent from the main Superset documentation. This allows us to update the component documentation as the components evolve, without affecting the main documentation.
+
+## Getting Started
+
+Browse the sidebar to explore the different components available in the library. Each component documentation includes:
+
+- Component description and purpose
+- Props and configuration options
+- Usage examples
+- Best practices

docs/components/layout-components/grid.md

@@ -0,0 +1,113 @@
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+---
+title: Grid
+sidebar_position: 1
+---
+
+# Grid Component
+
+The Grid component provides a flexible layout system for arranging content in rows and columns.
+
+## Props
+
+| Prop | Type | Default | Description |
+|------|------|---------|-------------|
+| `gutter` | `number` or `[number, number]` | `0` | Grid spacing between items, can be a single number or [horizontal, vertical] |
+| `columns` | `number` | `12` | Number of columns in the grid |
+| `justify` | `string` | `'start'` | Horizontal alignment: 'start', 'center', 'end', 'space-between', 'space-around' |
+| `align` | `string` | `'top'` | Vertical alignment: 'top', 'middle', 'bottom' |
+| `wrap` | `boolean` | `true` | Whether to wrap items when they overflow |
+
+### Row Props
+
+| Prop | Type | Default | Description |
+|------|------|---------|-------------|
+| `gutter` | `number` or `[number, number]` | `0` | Spacing between items in the row |
+| `justify` | `string` | `'start'` | Horizontal alignment for this row |
+| `align` | `string` | `'top'` | Vertical alignment for this row |
+
+### Col Props
+
+| Prop | Type | Default | Description |
+|------|------|---------|-------------|
+| `span` | `number` | - | Number of columns the grid item spans |
+| `offset` | `number` | `0` | Number of columns the grid item is offset |
+| `xs`, `sm`, `md`, `lg`, `xl` | `number` or `object` | - | Responsive props for different screen sizes |
+
+## Examples
+
+### Basic Grid
+
+```jsx
+import { Grid, Row, Col } from '@superset-ui/core';
+
+function Example() {
+  return (
+    <Grid>
+      <Row gutter={16}>
+        <Col span={8}>
+          <div>Column 1</div>
+        </Col>
+        <Col span={8}>
+          <div>Column 2</div>
+        </Col>
+        <Col span={8}>
+          <div>Column 3</div>
+        </Col>
+      </Row>
+    </Grid>
+  );
+}
+```
+
+### Responsive Grid
+
+```jsx
+import { Grid, Row, Col } from '@superset-ui/core';
+
+function Example() {
+  return (
+    <Grid>
+      <Row gutter={[16, 24]}>
+        <Col xs={24} sm={12} md={8} lg={6}>
+          <div>Responsive Column 1</div>
+        </Col>
+        <Col xs={24} sm={12} md={8} lg={6}>
+          <div>Responsive Column 2</div>
+        </Col>
+        <Col xs={24} sm={12} md={8} lg={6}>
+          <div>Responsive Column 3</div>
+        </Col>
+        <Col xs={24} sm={12} md={8} lg={6}>
+          <div>Responsive Column 4</div>
+        </Col>
+      </Row>
+    </Grid>
+  );
+}
+```
+
+## Best Practices
+
+- Use the Grid system for complex layouts that need to be responsive
+- Specify column widths for different screen sizes to ensure proper responsive behavior
+- Use gutters to create appropriate spacing between grid items
+- Keep the grid structure consistent throughout your application
+- Consider using the grid system for dashboard layouts to ensure consistent spacing and alignment

docs/components/test.mdx

@@ -0,0 +1,35 @@
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+---
+title: Test
+---
+
+import { StoryExample } from '../src/components/StorybookWrapper';
+
+# Test
+
+This is a test using our custom StorybookWrapper component.
+
+<StoryExample
+  component={() => (
+    <div style={{ padding: '10px', background: '#f0f0f0', borderRadius: '4px' }}>
+      This is a simple example component
+    </div>
+  )}
+/>

docs/components/ui-components/button.mdx

@@ -0,0 +1,146 @@
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+---
+title: Button Component
+sidebar_position: 1
+---
+
+import { StoryExample, StoryWithControls } from '../../src/components/StorybookWrapper';
+import { Button } from '../../../superset-frontend/packages/superset-ui-core/src/components/Button';
+
+# Button Component
+
+The Button component is a fundamental UI element used throughout Superset for user interactions.
+
+## Basic Usage
+
+The default button with primary styling:
+<StoryExample
+  component={() => (
+    <Button buttonStyle="primary" onClick={() => console.log('Clicked!')}>
+      Click Me
+    </Button>
+  )}
+/>
+
+## Interactive Example
+
+<StoryWithControls
+  component={({ buttonStyle, buttonSize, label, disabled }) => (
+    <Button
+      buttonStyle={buttonStyle}
+      buttonSize={buttonSize}
+      disabled={disabled}
+      onClick={() => console.log('Clicked!')}
+    >
+      {label}
+    </Button>
+  )}
+  props={{
+    buttonStyle: 'primary',
+    buttonSize: 'default',
+    label: 'Click Me',
+    disabled: false
+  }}
+  controls={[
+    {
+      name: 'buttonStyle',
+      label: 'Button Style',
+      type: 'select',
+      options: ['primary', 'secondary', 'tertiary', 'success', 'warning', 'danger', 'default', 'link', 'dashed']
+    },
+    {
+      name: 'buttonSize',
+      label: 'Button Size',
+      type: 'select',
+      options: ['default', 'small', 'xsmall']
+    },
+    {
+      name: 'label',
+      label: 'Button Text',
+      type: 'text'
+    },
+    {
+      name: 'disabled',
+      label: 'Disabled',
+      type: 'boolean'
+    }
+  ]}
+/>
+
+## Props
+
+| Prop | Type | Default | Description |
+|------|------|---------|-------------|
+| `buttonStyle` | `'primary' \| 'secondary' \| 'tertiary' \| 'success' \| 'warning' \| 'danger' \| 'default' \| 'link' \| 'dashed'` | `'default'` | Button style |
+| `buttonSize` | `'default' \| 'small' \| 'xsmall'` | `'default'` | Button size |
+| `disabled` | `boolean` | `false` | Whether the button is disabled |
+| `cta` | `boolean` | `false` | Whether the button is a call-to-action button |
+| `tooltip` | `ReactNode` | - | Tooltip content |
+| `placement` | `TooltipProps['placement']` | - | Tooltip placement |
+| `onClick` | `function` | - | Callback when button is clicked |
+| `href` | `string` | - | Turns button into an anchor link |
+| `target` | `string` | - | Target attribute for anchor links |
+
+## Usage
+
+```jsx
+import Button from 'src/components/Button';
+
+function MyComponent() {
+  return (
+    <Button
+      buttonStyle="primary"
+      onClick={() => console.log('Button clicked')}
+    >
+      Click Me
+    </Button>
+  );
+}
+```
+
+## Button Styles
+
+Superset provides a variety of button styles for different purposes:
+
+- **Primary**: Used for primary actions
+- **Secondary**: Used for secondary actions
+- **Tertiary**: Used for less important actions
+- **Success**: Used for successful or confirming actions
+- **Warning**: Used for actions that require caution
+- **Danger**: Used for destructive actions
+- **Link**: Used for navigation
+- **Dashed**: Used for adding new items or features
+
+## Button Sizes
+
+Buttons come in three sizes:
+
+- **Default**: Standard size for most use cases
+- **Small**: Compact size for tight spaces
+- **XSmall**: Extra small size for very limited spaces
+
+## Best Practices
+
+- Use primary buttons for the main action in a form or page
+- Use secondary buttons for alternative actions
+- Use danger buttons for destructive actions
+- Limit the number of primary buttons on a page to avoid confusion
+- Use consistent button styles throughout your application
+- Add tooltips to buttons when their purpose might not be immediately clear

docs/components/versions.json

@@ -0,0 +1 @@
+[]

docs/components_versions.json

@@ -0,0 +1 @@
+[]

docs/developer_portal/api/frontend.md

@@ -0,0 +1,477 @@
+---
+title: Frontend API Reference
+sidebar_position: 1
+hide_title: true
+---
+
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+
+# Frontend API Reference
+
+The `@apache-superset/core` package provides comprehensive APIs for frontend extension development. All APIs are organized into logical namespaces for easy discovery and use.
+
+## Core API
+
+The core namespace provides fundamental extension functionality.
+
+### registerView
+
+Registers a new view or panel in the specified contribution point.
+
+```typescript
+core.registerView(
+  id: string,
+  component: React.ComponentType
+): Disposable
+```
+
+**Example:**
+```typescript
+const panel = context.core.registerView('my-extension.panel', () => (
+  <MyPanelComponent />
+));
+```
+
+### getActiveView
+
+Gets the currently active view in a contribution area.
+
+```typescript
+core.getActiveView(area: string): View | undefined
+```
+
+## Commands API
+
+Manages command registration and execution.
+
+### registerCommand
+
+Registers a new command that can be triggered by menus, shortcuts, or programmatically.
+
+```typescript
+commands.registerCommand(
+  id: string,
+  handler: CommandHandler
+): Disposable
+
+interface CommandHandler {
+  title: string;
+  icon?: string;
+  execute: (...args: any[]) => any;
+  isEnabled?: (...args: any[]) => boolean;
+}
+```
+
+**Example:**
+```typescript
+const cmd = context.commands.registerCommand('my-extension.analyze', {
+  title: 'Analyze Query',
+  icon: 'BarChartOutlined',
+  execute: () => {
+    const query = context.sqlLab.getCurrentQuery();
+    // Perform analysis
+  },
+  isEnabled: () => {
+    return context.sqlLab.hasActiveEditor();
+  }
+});
+```
+
+### executeCommand
+
+Executes a registered command by ID.
+
+```typescript
+commands.executeCommand(id: string, ...args: any[]): Promise<any>
+```
+
+## SQL Lab API
+
+Provides access to SQL Lab functionality and events.
+
+### Query Access
+
+```typescript
+// Get current tab
+sqlLab.getCurrentTab(): Tab | undefined
+
+// Get all tabs
+sqlLab.getTabs(): Tab[]
+
+// Get current query
+sqlLab.getCurrentQuery(): string
+
+// Get selected text
+sqlLab.getSelectedText(): string | undefined
+```
+
+### Database Access
+
+```typescript
+// Get available databases
+sqlLab.getDatabases(): Database[]
+
+// Get database by ID
+sqlLab.getDatabase(id: number): Database | undefined
+
+// Get schemas for database
+sqlLab.getSchemas(databaseId: number): Promise<string[]>
+
+// Get tables for schema
+sqlLab.getTables(
+  databaseId: number,
+  schema: string
+): Promise<Table[]>
+```
+
+### Events
+
+```typescript
+// Query execution events
+sqlLab.onDidQueryRun: Event<QueryResult>
+sqlLab.onDidQueryStop: Event<QueryResult>
+sqlLab.onDidQueryFail: Event<QueryError>
+
+// Editor events
+sqlLab.onDidChangeEditorContent: Event<string>
+sqlLab.onDidChangeSelection: Event<Selection>
+
+// Tab events
+sqlLab.onDidChangeActiveTab: Event<Tab>
+sqlLab.onDidCloseTab: Event<Tab>
+sqlLab.onDidChangeTabTitle: Event<{tab: Tab, title: string}>
+
+// Panel events
+sqlLab.onDidOpenPanel: Event<Panel>
+sqlLab.onDidClosePanel: Event<Panel>
+sqlLab.onDidChangeActivePanel: Event<Panel>
+```
+
+**Event Usage Example:**
+```typescript
+const disposable = context.sqlLab.onDidQueryRun((result) => {
+  console.log('Query executed:', result.query);
+  console.log('Rows returned:', result.rowCount);
+  console.log('Execution time:', result.executionTime);
+});
+
+// Remember to dispose when done
+context.subscriptions.push(disposable);
+```
+
+## Authentication API
+
+Handles authentication and security tokens.
+
+### getCSRFToken
+
+Gets the current CSRF token for API requests.
+
+```typescript
+authentication.getCSRFToken(): Promise<string>
+```
+
+### getCurrentUser
+
+Gets information about the current user.
+
+```typescript
+authentication.getCurrentUser(): User
+
+interface User {
+  id: number;
+  username: string;
+  email: string;
+  roles: Role[];
+  permissions: Permission[];
+}
+```
+
+### hasPermission
+
+Checks if the current user has a specific permission.
+
+```typescript
+authentication.hasPermission(permission: string): boolean
+```
+
+## Extensions API
+
+Manages extension lifecycle and inter-extension communication.
+
+### getExtension
+
+Gets information about an installed extension.
+
+```typescript
+extensions.getExtension(id: string): Extension | undefined
+
+interface Extension {
+  id: string;
+  name: string;
+  version: string;
+  isActive: boolean;
+  metadata: ExtensionMetadata;
+}
+```
+
+### getActiveExtensions
+
+Gets all currently active extensions.
+
+```typescript
+extensions.getActiveExtensions(): Extension[]
+```
+
+### Events
+
+```typescript
+// Extension lifecycle events
+extensions.onDidActivateExtension: Event<Extension>
+extensions.onDidDeactivateExtension: Event<Extension>
+```
+
+## UI Components
+
+Import pre-built UI components from `@apache-superset/core`:
+
+```typescript
+import {
+  Button,
+  Select,
+  Input,
+  Table,
+  Modal,
+  Alert,
+  Tabs,
+  Card,
+  Dropdown,
+  Menu,
+  Tooltip,
+  Icon,
+  // ... many more
+} from '@apache-superset/core';
+```
+
+### Example Component Usage
+
+```typescript
+import { Button, Alert } from '@apache-superset/core';
+
+function MyExtensionPanel() {
+  return (
+    <div>
+      <Alert
+        message="Extension Loaded"
+        description="Your extension is ready to use"
+        type="success"
+      />
+      <Button
+        type="primary"
+        onClick={() => console.log('Clicked!')}
+      >
+        Execute Action
+      </Button>
+    </div>
+  );
+}
+```
+
+## Storage API
+
+Provides persistent storage for extension data.
+
+### Local Storage
+
+```typescript
+// Store data
+storage.local.set(key: string, value: any): Promise<void>
+
+// Retrieve data
+storage.local.get(key: string): Promise<any>
+
+// Remove data
+storage.local.remove(key: string): Promise<void>
+
+// Clear all extension data
+storage.local.clear(): Promise<void>
+```
+
+### Workspace Storage
+
+Workspace storage is shared across all users for collaborative features.
+
+```typescript
+storage.workspace.set(key: string, value: any): Promise<void>
+storage.workspace.get(key: string): Promise<any>
+storage.workspace.remove(key: string): Promise<void>
+```
+
+## Network API
+
+Utilities for making API calls to Superset.
+
+### fetch
+
+Enhanced fetch with CSRF token handling.
+
+```typescript
+network.fetch(url: string, options?: RequestInit): Promise<Response>
+```
+
+### API Client
+
+Type-safe API client for Superset endpoints.
+
+```typescript
+// Get chart data
+network.api.charts.get(id: number): Promise<Chart>
+
+// Query database
+network.api.sqlLab.execute(
+  databaseId: number,
+  query: string
+): Promise<QueryResult>
+
+// Get datasets
+network.api.datasets.list(): Promise<Dataset[]>
+```
+
+## Utility Functions
+
+### Formatting
+
+```typescript
+// Format numbers
+utils.formatNumber(value: number, format?: string): string
+
+// Format dates
+utils.formatDate(date: Date, format?: string): string
+
+// Format SQL
+utils.formatSQL(sql: string): string
+```
+
+### Validation
+
+```typescript
+// Validate SQL syntax
+utils.validateSQL(sql: string): ValidationResult
+
+// Check if valid database ID
+utils.isValidDatabaseId(id: any): boolean
+```
+
+## TypeScript Types
+
+Import common types for type safety:
+
+```typescript
+import type {
+  Database,
+  Dataset,
+  Chart,
+  Dashboard,
+  Query,
+  QueryResult,
+  Tab,
+  Panel,
+  User,
+  Role,
+  Permission,
+  ExtensionContext,
+  Disposable,
+  Event,
+  // ... more types
+} from '@apache-superset/core';
+```
+
+## Extension Context
+
+The context object passed to your extension's `activate` function:
+
+```typescript
+interface ExtensionContext {
+  // Subscription management
+  subscriptions: Disposable[];
+
+  // Extension metadata
+  extensionId: string;
+  extensionPath: string;
+
+  // API namespaces
+  core: CoreAPI;
+  commands: CommandsAPI;
+  sqlLab: SqlLabAPI;
+  authentication: AuthenticationAPI;
+  extensions: ExtensionsAPI;
+  storage: StorageAPI;
+  network: NetworkAPI;
+  utils: UtilsAPI;
+
+  // Logging
+  logger: Logger;
+}
+```
+
+## Event Handling
+
+Events follow the VS Code pattern with subscribe/dispose:
+
+```typescript
+// Subscribe to event
+const disposable = sqlLab.onDidQueryRun((result) => {
+  // Handle event
+});
+
+// Dispose when done
+disposable.dispose();
+
+// Or add to context for automatic cleanup
+context.subscriptions.push(disposable);
+```
+
+## Best Practices
+
+1. **Always dispose subscriptions** to prevent memory leaks
+2. **Use TypeScript** for better IDE support and type safety
+3. **Handle errors gracefully** with try-catch blocks
+4. **Check permissions** before sensitive operations
+5. **Use provided UI components** for consistency
+6. **Cache API responses** when appropriate
+7. **Validate user input** before processing
+
+## Version Compatibility
+
+The frontend API follows semantic versioning:
+
+- **Major version**: Breaking changes
+- **Minor version**: New features, backward compatible
+- **Patch version**: Bug fixes
+
+Check compatibility in your `extension.json`:
+
+```json
+{
+  "engines": {
+    "@apache-superset/core": "^1.0.0"
+  }
+}
+```

docs/developer_portal/architecture/overview.md

@@ -0,0 +1,348 @@
+---
+title: Architecture Overview
+sidebar_position: 1
+hide_title: true
+---
+
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+
+# Extension Architecture Overview
+
+The Superset extension architecture is designed to be modular, secure, and performant. This document provides a comprehensive overview of how extensions work and interact with the Superset host application.
+
+## Core Principles
+
+### 1. Lean Core
+Superset's core remains minimal, with features delegated to extensions wherever possible. Built-in features use the same APIs as external extensions, ensuring API quality through dogfooding.
+
+### 2. Explicit Contribution Points
+All extension points are clearly defined and documented. Extensions declare their capabilities in metadata files, enabling predictable lifecycle management.
+
+### 3. Versioned APIs
+Public interfaces follow semantic versioning, ensuring backward compatibility and safe evolution of the platform.
+
+### 4. Lazy Loading
+Extensions load only when needed, minimizing performance impact and resource consumption.
+
+### 5. Composability
+Architecture patterns and APIs are reusable across different Superset modules, promoting consistency.
+
+### 6. Community-Driven
+The system evolves based on real-world feedback, with new extension points added as needs emerge.
+
+## System Architecture
+
+```mermaid
+graph TB
+    subgraph "Superset Host Application"
+        Core[Core Application]
+        API[Extension APIs]
+        Loader[Extension Loader]
+        Manager[Extension Manager]
+    end
+
+    subgraph "Core Packages"
+        FrontendCore["@apache-superset/core<br/>(Frontend)"]
+        BackendCore["apache-superset-core<br/>(Backend)"]
+        CLI["apache-superset-extensions-cli"]
+    end
+
+    subgraph "Extension"
+        Metadata[extension.json]
+        Frontend[Frontend Code]
+        Backend[Backend Code]
+        Bundle[.supx Bundle]
+    end
+
+    Core --> API
+    API --> FrontendCore
+    API --> BackendCore
+    Loader --> Manager
+    Manager --> Bundle
+    Frontend --> FrontendCore
+    Backend --> BackendCore
+    CLI --> Bundle
+```
+
+## Key Components
+
+### Host Application
+
+The Superset host application provides:
+
+- **Extension APIs**: Well-defined interfaces for extensions to interact with Superset
+- **Extension Manager**: Handles lifecycle, activation, and deactivation
+- **Module Loader**: Dynamically loads extension code using Webpack Module Federation
+- **Security Context**: Manages permissions and sandboxing for extensions
+
+### Core Packages
+
+#### @apache-superset/core (Frontend)
+- Shared UI components and utilities
+- TypeScript type definitions
+- Frontend API implementations
+- Event system and command registry
+
+#### apache-superset-core (Backend)
+- Python base classes and utilities
+- Database access APIs
+- Security and permission helpers
+- REST API registration
+
+#### apache-superset-extensions-cli
+- Project scaffolding
+- Build and bundling tools
+- Development server
+- Package management
+
+### Extension Structure
+
+Each extension consists of:
+
+- **Metadata** (`extension.json`): Declares capabilities and requirements
+- **Frontend**: React components and TypeScript code
+- **Backend**: Python modules and API endpoints
+- **Assets**: Styles, images, and other resources
+- **Bundle** (`.supx`): Packaged distribution format
+
+## Module Federation
+
+Extensions use Webpack Module Federation for dynamic loading:
+
+```javascript
+// Extension webpack.config.js
+new ModuleFederationPlugin({
+  name: 'my_extension',
+  filename: 'remoteEntry.[contenthash].js',
+  exposes: {
+    './index': './src/index.tsx',
+  },
+  externals: {
+    '@apache-superset/core': 'superset',
+  },
+  shared: {
+    react: { singleton: true },
+    'react-dom': { singleton: true },
+  }
+})
+```
+
+This allows:
+- **Independent builds**: Extensions compile separately from Superset
+- **Shared dependencies**: Common libraries like React aren't duplicated
+- **Dynamic loading**: Extensions load at runtime without rebuilding Superset
+- **Version compatibility**: Extensions declare compatible core versions
+
+## Extension Lifecycle
+
+### 1. Registration
+```typescript
+// Extension registered with host
+extensionManager.register({
+  name: 'my-extension',
+  version: '1.0.0',
+  manifest: manifestData
+});
+```
+
+### 2. Activation
+```typescript
+// activate() called when extension loads
+export function activate(context: ExtensionContext) {
+  // Register contributions
+  const disposables = [];
+
+  // Add panel
+  disposables.push(
+    context.core.registerView('my-panel', MyPanel)
+  );
+
+  // Register command
+  disposables.push(
+    context.commands.registerCommand('my-command', {
+      execute: () => { /* ... */ }
+    })
+  );
+
+  // Store for cleanup
+  context.subscriptions.push(...disposables);
+}
+```
+
+### 3. Runtime
+- Extension responds to events
+- Provides UI components when requested
+- Executes commands when triggered
+- Accesses APIs as needed
+
+### 4. Deactivation
+```typescript
+// Automatic cleanup of registered items
+export function deactivate() {
+  // context.subscriptions automatically disposed
+  // Additional cleanup if needed
+}
+```
+
+## Contribution Types
+
+### Views
+Extensions can add panels and UI components:
+
+```json
+{
+  "views": {
+    "sqllab.panels": [{
+      "id": "my-panel",
+      "name": "My Panel",
+      "icon": "ToolOutlined"
+    }]
+  }
+}
+```
+
+### Commands
+Define executable actions:
+
+```json
+{
+  "commands": [{
+    "command": "my-extension.run",
+    "title": "Run Analysis",
+    "icon": "PlayCircleOutlined"
+  }]
+}
+```
+
+### Menus
+Add items to existing menus:
+
+```json
+{
+  "menus": {
+    "sqllab.editor": {
+      "primary": [{
+        "command": "my-extension.run",
+        "when": "editorHasSelection"
+      }]
+    }
+  }
+}
+```
+
+### API Endpoints
+Register backend REST endpoints:
+
+```python
+from superset_core.api import rest_api
+
+@rest_api.route('/my-endpoint')
+def my_endpoint():
+    return {'data': 'value'}
+```
+
+## Security Model
+
+### Permissions
+- Extensions run with user's permissions
+- No elevation of privileges
+- Access controlled by Superset's RBAC
+
+### Sandboxing
+- Frontend code runs in browser context
+- Backend code runs in Python process
+- Future: Optional sandboxed execution
+
+### Validation
+- Manifest validation on upload
+- Signature verification (future)
+- Dependency scanning
+
+## Performance Considerations
+
+### Lazy Loading
+- Extensions load only when features are accessed
+- Code splitting for large extensions
+- Cached after first load
+
+### Bundle Optimization
+- Tree shaking removes unused code
+- Minification reduces size
+- Compression for network transfer
+
+### Resource Management
+- Automatic cleanup on deactivation
+- Memory leak prevention
+- Event listener management
+
+## Development vs Production
+
+### Development Mode
+```python
+# superset_config.py
+ENABLE_EXTENSIONS = True
+LOCAL_EXTENSIONS = ['/path/to/extension']
+```
+- Hot reloading
+- Source maps
+- Debug logging
+
+### Production Mode
+- Optimized bundles
+- Cached assets
+- Performance monitoring
+
+## Future Enhancements
+
+### Planned Features
+- Enhanced sandboxing
+- Extension marketplace
+- Inter-extension communication
+- Theme contributions
+- Chart type extensions
+
+### API Expansion
+- Dashboard extensions
+- Database connector API
+- Security provider interface
+- Workflow automation
+
+## Best Practices
+
+### Do's
+- ✅ Use TypeScript for type safety
+- ✅ Follow semantic versioning
+- ✅ Handle errors gracefully
+- ✅ Clean up resources properly
+- ✅ Document your extension
+
+### Don'ts
+- ❌ Access private APIs
+- ❌ Modify global state directly
+- ❌ Block the main thread
+- ❌ Store sensitive data insecurely
+- ❌ Assume API stability in 0.x versions
+
+## Learn More
+
+- [API Reference](../api/frontend)
+- [Development Guide](../getting-started)
+- [Security Guidelines](./security)
+- [Performance Optimization](./performance)

docs/developer_portal/cli/overview.md

@@ -0,0 +1,466 @@
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+---
+title: CLI Documentation
+sidebar_position: 1
+hide_title: true
+---
+
+# Superset Extensions CLI
+
+The `apache-superset-extensions-cli` provides command-line tools for creating, developing, and packaging Superset extensions.
+
+## Installation
+
+```bash
+pip install apache-superset-extensions-cli
+```
+
+## Commands
+
+### init
+
+Creates a new extension project with the standard folder structure.
+
+```bash
+superset-extensions init <extension-name> [options]
+```
+
+**Options:**
+- `--template <template>`: Use a specific template (default: basic)
+- `--author <name>`: Set the author name
+- `--description <text>`: Set the extension description
+- `--with-backend`: Include backend code structure
+
+**Example:**
+```bash
+superset-extensions init my-extension \
+  --author "John Doe" \
+  --description "Adds custom analytics to SQL Lab" \
+  --with-backend
+```
+
+**Generated Structure:**
+```
+my-extension/
+├── extension.json
+├── frontend/
+│   ├── src/
+│   │   └── index.tsx
+│   ├── package.json
+│   ├── tsconfig.json
+│   └── webpack.config.js
+├── backend/
+│   ├── src/
+│   │   └── my_extension/
+│   │       ├── __init__.py
+│   │       └── entrypoint.py
+│   ├── tests/
+│   ├── pyproject.toml
+│   └── requirements.txt
+└── README.md
+```
+
+### dev
+
+Starts the development server with hot reloading.
+
+```bash
+superset-extensions dev [options]
+```
+
+**Options:**
+- `--port <port>`: Development server port (default: 9001)
+- `--host <host>`: Development server host (default: localhost)
+- `--no-watch`: Disable file watching
+- `--verbose`: Show detailed output
+
+**Example:**
+```bash
+# Start development server
+superset-extensions dev
+
+# Output:
+⚙️  Building frontend assets...
+✅ Frontend rebuilt
+✅ Backend files synced
+✅ Manifest updated
+👀 Watching for changes...
+```
+
+### build
+
+Builds the extension for production.
+
+```bash
+superset-extensions build [options]
+```
+
+**Options:**
+- `--mode <mode>`: Build mode (development | production)
+- `--analyze`: Generate bundle analysis
+- `--source-maps`: Include source maps
+
+**Example:**
+```bash
+# Production build
+superset-extensions build --mode production
+
+# With analysis
+superset-extensions build --analyze
+```
+
+### bundle
+
+Creates a `.supx` package for distribution.
+
+```bash
+superset-extensions bundle [options]
+```
+
+**Options:**
+- `--output <path>`: Output directory (default: current)
+- `--sign`: Sign the package (requires certificate)
+- `--compress`: Compression level (0-9, default: 6)
+
+**Example:**
+```bash
+# Create bundle
+superset-extensions bundle
+
+# Creates: my-extension-1.0.0.supx
+```
+
+### validate
+
+Validates extension configuration and structure.
+
+```bash
+superset-extensions validate [options]
+```
+
+**Options:**
+- `--fix`: Auto-fix common issues
+- `--strict`: Enable strict validation
+
+**Checks:**
+- Valid extension.json syntax
+- Required files present
+- Dependency versions
+- Module exports
+- TypeScript configuration
+
+**Example:**
+```bash
+superset-extensions validate --strict
+
+# Output:
+✅ extension.json valid
+✅ Frontend structure valid
+✅ Backend structure valid
+⚠️  Warning: Missing LICENSE file
+✅ Validation passed with warnings
+```
+
+### test
+
+Runs extension tests.
+
+```bash
+superset-extensions test [options]
+```
+
+**Options:**
+- `--coverage`: Generate coverage report
+- `--watch`: Run in watch mode
+- `--frontend-only`: Run only frontend tests
+- `--backend-only`: Run only backend tests
+
+**Example:**
+```bash
+# Run all tests
+superset-extensions test --coverage
+
+# Watch mode for frontend
+superset-extensions test --frontend-only --watch
+```
+
+### publish
+
+Publishes extension to a registry (future feature).
+
+```bash
+superset-extensions publish [options]
+```
+
+**Options:**
+- `--registry <url>`: Registry URL
+- `--token <token>`: Authentication token
+- `--dry-run`: Simulate publish
+
+## Configuration
+
+### Project Configuration
+
+The CLI reads configuration from multiple sources:
+
+1. **extension.json** - Extension metadata
+2. **package.json** - Frontend dependencies
+3. **pyproject.toml** - Backend configuration
+4. **.extensionrc** - CLI-specific settings
+
+### .extensionrc Example
+
+```json
+{
+  "dev": {
+    "port": 9001,
+    "host": "localhost",
+    "autoReload": true
+  },
+  "build": {
+    "mode": "production",
+    "sourceMaps": false,
+    "optimization": true
+  },
+  "test": {
+    "coverage": true,
+    "threshold": {
+      "statements": 80,
+      "branches": 70,
+      "functions": 80,
+      "lines": 80
+    }
+  }
+}
+```
+
+## Templates
+
+### Available Templates
+
+- **basic**: Simple extension with frontend only
+- **full-stack**: Frontend and backend components
+- **sql-panel**: SQL Lab panel extension
+- **api-only**: Backend API extension
+- **chart-plugin**: Custom chart visualization
+
+### Using Templates
+
+```bash
+# Use specific template
+superset-extensions init my-chart --template chart-plugin
+
+# List available templates
+superset-extensions init --list-templates
+```
+
+### Custom Templates
+
+Create custom templates in `~/.superset-extensions/templates/`:
+
+```
+~/.superset-extensions/templates/
+└── my-template/
+    ├── template.json
+    └── files/
+        └── ... template files ...
+```
+
+## Development Workflow
+
+### 1. Create Extension
+
+```bash
+superset-extensions init awesome-feature
+cd awesome-feature
+```
+
+### 2. Install Dependencies
+
+```bash
+# Frontend
+cd frontend && npm install
+
+# Backend (if applicable)
+cd ../backend && pip install -r requirements.txt
+```
+
+### 3. Configure Superset
+
+```python
+# superset_config.py
+ENABLE_EXTENSIONS = True
+LOCAL_EXTENSIONS = [
+    "/path/to/awesome-feature"
+]
+```
+
+### 4. Start Development
+
+```bash
+# Terminal 1: Extension dev server
+superset-extensions dev
+
+# Terminal 2: Superset
+superset run -p 8088 --reload
+```
+
+### 5. Test Changes
+
+Make changes to your code and see them reflected immediately in Superset.
+
+### 6. Build and Package
+
+```bash
+# Validate
+superset-extensions validate
+
+# Test
+superset-extensions test
+
+# Build
+superset-extensions build --mode production
+
+# Bundle
+superset-extensions bundle
+```
+
+### 7. Deploy
+
+Upload the `.supx` file to your Superset instance.
+
+## Environment Variables
+
+The CLI respects these environment variables:
+
+- `SUPERSET_EXTENSIONS_DEV_PORT`: Development server port
+- `SUPERSET_EXTENSIONS_DEV_HOST`: Development server host
+- `SUPERSET_BASE_URL`: Superset instance URL
+- `NODE_ENV`: Node environment (development/production)
+- `PYTHONPATH`: Python module search path
+
+## Troubleshooting
+
+### Common Issues
+
+#### Port Already in Use
+
+```bash
+# Use different port
+superset-extensions dev --port 9002
+```
+
+#### Module Federation Errors
+
+```bash
+# Rebuild with clean cache
+rm -rf dist/ node_modules/.cache
+superset-extensions build
+```
+
+#### Python Import Errors
+
+```bash
+# Ensure virtual environment is activated
+source venv/bin/activate
+superset-extensions dev
+```
+
+### Debug Mode
+
+Enable verbose output for troubleshooting:
+
+```bash
+# Verbose output
+superset-extensions dev --verbose
+
+# Debug webpack
+DEBUG=webpack:* superset-extensions build
+```
+
+## Best Practices
+
+1. **Version Control**: Commit `extension.json` but not `dist/`
+2. **Dependencies**: Pin versions in package.json
+3. **Testing**: Write tests for critical functionality
+4. **Documentation**: Keep README.md updated
+5. **Validation**: Run validate before bundling
+6. **Semantic Versioning**: Follow semver for releases
+
+## Advanced Usage
+
+### Custom Webpack Configuration
+
+Extend the default webpack config:
+
+```javascript
+// webpack.config.js
+const baseConfig = require('./webpack.base.config');
+
+module.exports = {
+  ...baseConfig,
+  // Custom modifications
+  resolve: {
+    ...baseConfig.resolve,
+    alias: {
+      '@': path.resolve(__dirname, 'src'),
+    },
+  },
+};
+```
+
+### CI/CD Integration
+
+```yaml
+# .github/workflows/extension.yml
+name: Extension CI
+
+on: [push, pull_request]
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+      - uses: actions/setup-python@v2
+
+      - name: Install CLI
+        run: pip install apache-superset-extensions-cli
+
+      - name: Validate
+        run: superset-extensions validate --strict
+
+      - name: Test
+        run: superset-extensions test --coverage
+
+      - name: Build
+        run: superset-extensions build --mode production
+
+      - name: Bundle
+        run: superset-extensions bundle
+```
+
+## Getting Help
+
+- **Documentation**: [Developer Portal](../)
+- **Examples**: [GitHub Repository](https://github.com/apache/superset/tree/master/extensions)
+- **Issues**: [GitHub Issues](https://github.com/apache/superset/issues)
+- **Community**: [Slack Channel](https://apache-superset.slack.com)

docs/developer_portal/examples/index.md

@@ -0,0 +1,464 @@
+---
+title: Extension Examples
+sidebar_position: 1
+hide_title: true
+---
+
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+
+# Extension Examples
+
+Learn from real-world extension implementations that showcase different capabilities of the Superset extension system.
+
+## Dataset References Panel
+
+A SQL Lab panel that analyzes queries and displays information about referenced tables.
+
+### Features
+- Parses SQL to extract table references
+- Shows table owners and permissions
+- Displays last partition information
+- Provides row count estimates
+
+### Key Implementation
+
+```typescript
+// Parse SQL and extract tables
+function extractTables(sql: string): TableReference[] {
+  const tables = [];
+  const tableRegex = /FROM\s+(\w+\.?\w+)/gi;
+  let match;
+
+  while ((match = tableRegex.exec(sql)) !== null) {
+    tables.push({
+      schema: match[1].split('.')[0],
+      table: match[1].split('.')[1] || match[1],
+    });
+  }
+
+  return tables;
+}
+
+// Register panel
+export function activate(context: ExtensionContext) {
+  const panel = context.core.registerView('dataset-references.panel', () => (
+    <DatasetReferencesPanel />
+  ));
+
+  // Listen for query changes
+  const listener = context.sqlLab.onDidChangeEditorContent((content) => {
+    const tables = extractTables(content);
+    updatePanelWithTables(tables);
+  });
+
+  context.subscriptions.push(panel, listener);
+}
+```
+
+### Manifest
+
+```json
+{
+  "name": "dataset-references",
+  "contributions": {
+    "views": {
+      "sqllab.panels": [{
+        "id": "dataset-references.panel",
+        "name": "Dataset References",
+        "icon": "DatabaseOutlined",
+        "location": "right"
+      }]
+    }
+  }
+}
+```
+
+## Query Optimizer
+
+Analyzes SQL queries and suggests optimizations.
+
+### Features
+- Detects missing indexes
+- Suggests query rewrites
+- Identifies expensive operations
+- Provides execution plan analysis
+
+### Implementation Highlights
+
+```typescript
+// Register optimization command
+const optimizeCommand = context.commands.registerCommand('query-optimizer.analyze', {
+  title: 'Analyze Query Performance',
+  icon: 'ThunderboltOutlined',
+  execute: async () => {
+    const query = context.sqlLab.getCurrentQuery();
+    const database = context.sqlLab.getCurrentDatabase();
+
+    // Get execution plan
+    const plan = await getExecutionPlan(database.id, query);
+
+    // Analyze and suggest improvements
+    const suggestions = analyzeExecutionPlan(plan);
+
+    // Show results in panel
+    showOptimizationResults(suggestions);
+  }
+});
+
+// Add to editor menu
+"menus": {
+  "sqllab.editor": {
+    "primary": [{
+      "command": "query-optimizer.analyze",
+      "when": "editorHasContent"
+    }]
+  }
+}
+```
+
+## Natural Language to SQL
+
+Converts natural language questions to SQL queries using LLM integration.
+
+### Features
+- Natural language input
+- Context-aware SQL generation
+- Query validation
+- History tracking
+
+### Key Components
+
+```typescript
+// Backend API endpoint
+@rest_api.route('/nl2sql/generate')
+def generate_sql(prompt: str, context: dict):
+    # Use LLM to generate SQL
+    sql = llm_client.generate(
+        prompt=prompt,
+        schema=context['schema'],
+        examples=context['examples']
+    )
+
+    # Validate generated SQL
+    validation = validate_sql(sql)
+
+    return {
+        'sql': sql,
+        'valid': validation.is_valid,
+        'errors': validation.errors
+    }
+```
+
+```typescript
+// Frontend integration
+function NL2SQLPanel() {
+  const [prompt, setPrompt] = useState('');
+  const [loading, setLoading] = useState(false);
+
+  const generateSQL = async () => {
+    setLoading(true);
+
+    const response = await context.network.api.post('/extensions/nl2sql/generate', {
+      prompt,
+      context: {
+        database: context.sqlLab.getCurrentDatabase(),
+        schema: await context.sqlLab.getCurrentSchema(),
+      }
+    });
+
+    if (response.valid) {
+      // Insert SQL into editor
+      context.sqlLab.insertText(response.sql);
+    }
+
+    setLoading(false);
+  };
+
+  return (
+    <div>
+      <Input.TextArea
+        value={prompt}
+        onChange={(e) => setPrompt(e.target.value)}
+        placeholder="Describe what data you want..."
+      />
+      <Button onClick={generateSQL} loading={loading}>
+        Generate SQL
+      </Button>
+    </div>
+  );
+}
+```
+
+## Schema Visualizer
+
+Interactive database schema visualization.
+
+### Features
+- Visual ERD diagram
+- Table relationships
+- Column details on hover
+- Export to image
+
+### Implementation
+
+```typescript
+import { Graph } from '@antv/g6';
+
+function SchemaVisualizer() {
+  const containerRef = useRef<HTMLDivElement>(null);
+  const [graph, setGraph] = useState<Graph>();
+
+  useEffect(() => {
+    if (!containerRef.current) return;
+
+    const g = new Graph({
+      container: containerRef.current,
+      layout: {
+        type: 'dagre',
+        rankdir: 'LR',
+      },
+      defaultNode: {
+        type: 'sql-table-node',
+      },
+      defaultEdge: {
+        type: 'sql-relation-edge',
+      },
+    });
+
+    setGraph(g);
+    loadSchemaData(g);
+
+    return () => g.destroy();
+  }, []);
+
+  const loadSchemaData = async (g: Graph) => {
+    const tables = await context.sqlLab.getTables();
+    const nodes = tables.map(table => ({
+      id: table.name,
+      label: table.name,
+      columns: table.columns,
+    }));
+
+    const edges = extractRelationships(tables);
+
+    g.data({ nodes, edges });
+    g.render();
+  };
+
+  return <div ref={containerRef} style={{ height: '100%' }} />;
+}
+```
+
+## SQL Formatter
+
+Formats and beautifies SQL code with customizable rules.
+
+### Features
+- Multiple formatting styles
+- Custom rule configuration
+- Batch formatting
+- Format on save
+
+### Simple Implementation
+
+```typescript
+import { format } from 'sql-formatter';
+
+const formatCommand = context.commands.registerCommand('sql-formatter.format', {
+  title: 'Format SQL',
+  execute: () => {
+    const sql = context.sqlLab.getCurrentQuery();
+
+    const formatted = format(sql, {
+      language: 'sql',
+      indent: '  ',
+      uppercase: true,
+      linesBetweenQueries: 2,
+    });
+
+    context.sqlLab.replaceQuery(formatted);
+  }
+});
+
+// Auto-format on save
+context.sqlLab.onWillSaveQuery((event) => {
+  if (context.storage.local.get('autoFormat')) {
+    const formatted = format(event.query);
+    event.waitUntil(Promise.resolve(formatted));
+  }
+});
+```
+
+## Query History Search
+
+Enhanced query history with advanced search and filtering.
+
+### Features
+- Full-text search
+- Filter by date, user, database
+- Query statistics
+- Export capabilities
+
+### UI Component
+
+```typescript
+function QueryHistoryPanel() {
+  const [queries, setQueries] = useState<Query[]>([]);
+  const [filters, setFilters] = useState<Filters>({});
+
+  useEffect(() => {
+    loadQueries();
+  }, [filters]);
+
+  const loadQueries = async () => {
+    const history = await context.network.api.get('/api/v1/query', {
+      params: {
+        ...filters,
+        page_size: 100,
+      }
+    });
+
+    setQueries(history.result);
+  };
+
+  return (
+    <div>
+      <SearchFilters onChange={setFilters} />
+      <Table
+        dataSource={queries}
+        columns={[
+          { title: 'Query', dataIndex: 'sql', ellipsis: true },
+          { title: 'Database', dataIndex: 'database' },
+          { title: 'Status', dataIndex: 'status' },
+          { title: 'Duration', dataIndex: 'duration' },
+          { title: 'User', dataIndex: 'user' },
+          {
+            title: 'Actions',
+            render: (query) => (
+              <Button
+                icon={<CopyOutlined />}
+                onClick={() => context.sqlLab.insertText(query.sql)}
+              />
+            ),
+          },
+        ]}
+      />
+    </div>
+  );
+}
+```
+
+## Git Integration
+
+Version control for SQL queries and dashboards.
+
+### Features
+- Save queries to Git
+- Track changes
+- Collaborative editing
+- Branch management
+
+### Backend Integration
+
+```python
+from git import Repo
+
+class GitExtension:
+    def __init__(self, repo_path):
+        self.repo = Repo(repo_path)
+
+    def save_query(self, query, message):
+        # Save query to file
+        path = f"queries/{query.name}.sql"
+        with open(path, 'w') as f:
+            f.write(query.sql)
+
+        # Commit to Git
+        self.repo.index.add([path])
+        self.repo.index.commit(message)
+
+        return {
+            'status': 'success',
+            'commit': self.repo.head.commit.hexsha
+        }
+```
+
+## Best Practices from Examples
+
+### 1. User Experience
+- Provide clear feedback for async operations
+- Handle errors gracefully
+- Include loading states
+- Add keyboard shortcuts
+
+### 2. Performance
+- Debounce expensive operations
+- Cache API responses
+- Use virtual scrolling for large lists
+- Lazy load heavy components
+
+### 3. Integration
+- Respect Superset's theme
+- Use provided UI components
+- Follow existing UX patterns
+- Integrate with existing menus
+
+### 4. Code Organization
+```
+extension/
+├── frontend/
+│   ├── src/
+│   │   ├── components/     # UI components
+│   │   ├── hooks/          # Custom hooks
+│   │   ├── services/       # API services
+│   │   ├── utils/          # Utilities
+│   │   └── index.tsx       # Entry point
+│   └── tests/
+├── backend/
+│   ├── src/
+│   │   ├── api/           # REST endpoints
+│   │   ├── models/        # Data models
+│   │   ├── services/      # Business logic
+│   │   └── entrypoint.py
+│   └── tests/
+```
+
+### 5. Testing
+```typescript
+// Test example
+describe('DatasetReferences', () => {
+  it('should extract tables from SQL', () => {
+    const sql = 'SELECT * FROM users JOIN orders ON users.id = orders.user_id';
+    const tables = extractTables(sql);
+
+    expect(tables).toEqual([
+      { schema: 'public', table: 'users' },
+      { schema: 'public', table: 'orders' },
+    ]);
+  });
+});
+```
+
+## Learn More
+
+- [API Reference](../api/frontend)
+- [Architecture Overview](../architecture/overview)
+- [Getting Started Guide](../getting-started)
+- [CLI Documentation](../cli/overview)

docs/developer_portal/getting-started/index.md

@@ -0,0 +1,248 @@
+---
+title: Getting Started
+sidebar_position: 2
+hide_title: true
+---
+
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+
+# Getting Started with Extensions
+
+This guide will walk you through creating, developing, and deploying your first Superset extension.
+
+## Prerequisites
+
+Before you begin, make sure you have:
+
+- **Node.js 16+** and npm/yarn installed
+- **Python 3.9+** and pip installed  
+- **Superset** running locally or access to a Superset instance
+- **Git** for version control
+- Basic knowledge of React and TypeScript
+
+## Quick Start
+
+### 1. Install the CLI
+
+First, install the Superset Extensions CLI globally:
+
+```bash
+pip install apache-superset-extensions-cli
+```
+
+### 2. Create Your First Extension
+
+Use the CLI to scaffold a new extension project:
+
+```bash
+superset-extensions init my-first-extension
+cd my-first-extension
+```
+
+This creates the following structure:
+
+```
+my-first-extension/
+├── extension.json          # Extension metadata
+├── frontend/              # Frontend code
+│   ├── src/
+│   │   └── index.tsx     # Main entry point
+│   ├── package.json
+│   └── webpack.config.js
+├── backend/              # Backend code (optional)
+│   ├── src/
+│   └── requirements.txt
+└── README.md
+```
+
+### 3. Configure Your Extension
+
+Edit `extension.json` to define your extension's capabilities:
+
+```json
+{
+  "name": "my-first-extension",
+  "version": "1.0.0",
+  "description": "My first Superset extension",
+  "author": "Your Name",
+  "frontend": {
+    "contributions": {
+      "views": {
+        "sqllab.panels": [
+          {
+            "id": "my-extension.main",
+            "name": "My Panel",
+            "icon": "ToolOutlined"
+          }
+        ]
+      }
+    }
+  }
+}
+```
+
+### 4. Develop Your Extension
+
+Edit `frontend/src/index.tsx` to implement your extension:
+
+```typescript
+import React from 'react';
+import { ExtensionContext } from '@apache-superset/core';
+
+export function activate(context: ExtensionContext) {
+  // Register your panel component
+  const panel = context.core.registerView('my-extension.main', () => (
+    <div style={{ padding: 20 }}>
+      <h2>Hello from My Extension!</h2>
+      <p>This is my first Superset extension.</p>
+    </div>
+  ));
+
+  // Clean up on deactivation
+  context.subscriptions.push(panel);
+}
+
+export function deactivate() {
+  // Cleanup code if needed
+}
+```
+
+### 5. Test Locally
+
+Enable development mode in your Superset configuration:
+
+```python
+# superset_config.py
+ENABLE_EXTENSIONS = True
+LOCAL_EXTENSIONS = [
+    "/path/to/my-first-extension"
+]
+```
+
+Run the development server:
+
+```bash
+# In your extension directory
+superset-extensions dev
+
+# In a separate terminal, start Superset
+superset run -p 8088 --with-threads --reload
+```
+
+Your extension will now appear in SQL Lab!
+
+### 6. Build and Package
+
+When ready to distribute your extension:
+
+```bash
+superset-extensions build
+superset-extensions bundle
+```
+
+This creates a `my-first-extension-1.0.0.supx` file that can be uploaded to any Superset instance.
+
+### 7. Deploy
+
+Upload your extension via the Superset UI or API:
+
+```bash
+curl -X POST http://localhost:8088/api/v1/extensions/import/ \
+  -H "Authorization: Bearer YOUR_TOKEN" \
+  -F "file=@my-first-extension-1.0.0.supx"
+```
+
+## What's Next?
+
+Now that you have a basic extension working, explore:
+
+- [Extension Architecture](../architecture/overview) - Understand how extensions work
+- [API Reference](../api/frontend) - Learn about available APIs
+- [Examples](../examples) - See more complex extension examples
+- [Best Practices](./best-practices) - Learn extension development best practices
+
+## Common Patterns
+
+### Adding a SQL Lab Panel
+
+```typescript
+const panel = context.core.registerView('my-extension.panel', () => (
+  <MyPanelComponent />
+));
+```
+
+### Registering Commands
+
+```typescript
+const command = context.commands.registerCommand('my-extension.run', {
+  title: 'Run My Command',
+  execute: () => {
+    // Command logic
+  }
+});
+```
+
+### Listening to Events
+
+```typescript
+const listener = context.sqlLab.onDidQueryRun((query) => {
+  console.log('Query executed:', query);
+});
+```
+
+### Adding Menu Items
+
+```json
+{
+  "menus": {
+    "sqllab.editor": {
+      "primary": [{
+        "command": "my-extension.run",
+        "when": "editorHasSelection"
+      }]
+    }
+  }
+}
+```
+
+## Troubleshooting
+
+### Extension Not Loading
+
+- Ensure `ENABLE_EXTENSIONS = True` in your config
+- Check the browser console for errors
+- Verify the extension path in `LOCAL_EXTENSIONS`
+
+### Module Not Found Errors
+
+- Run `npm install` in the frontend directory
+- Check that `@apache-superset/core` is properly externalized
+
+### Build Failures
+
+- Ensure all dependencies are installed
+- Check webpack.config.js for proper Module Federation setup
+- Verify extension.json is valid JSON
+
+## Get Help
+
+- Join the [Superset Slack](https://join.slack.com/t/apache-superset/shared_invite/zt-16jvzmoi8-sI1TY1Pm~y_RnSiUAN0jqQ)
+- Ask questions on [GitHub Discussions](https://github.com/apache/superset/discussions)
+- Report issues on [GitHub Issues](https://github.com/apache/superset/issues)

docs/developer_portal/index.md

@@ -0,0 +1,126 @@
+---
+title: Developer Portal
+sidebar_position: 1
+hide_title: true
+---
+
+<!--
+    Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+    Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+-->
+
+# Superset Developer Portal
+
+Welcome to the Apache Superset Developer Portal! This is your comprehensive guide to extending and customizing Superset through our new extension architecture.
+
+## What are Superset Extensions?
+
+Superset Extensions provide a powerful way to enhance and customize Apache Superset without modifying the core codebase. Following the successful model pioneered by VS Code, our extension architecture enables developers to:
+
+- **Add custom features** to SQL Lab and other Superset modules
+- **Create reusable components** that can be shared across organizations
+- **Integrate external tools** and services seamlessly
+- **Customize workflows** to match your team's specific needs
+
+## Why Extensions?
+
+As Superset has grown, we've recognized the need for a more modular architecture that allows:
+
+- **Innovation without fragmentation** - Build features without forking the codebase
+- **Community-driven development** - Share and reuse extensions across organizations
+- **Stable APIs** - Develop against versioned, well-documented interfaces
+- **Rapid iteration** - Deploy custom features without waiting for core releases
+
+## Key Features
+
+### 🎯 Well-Defined Extension Points
+
+Extensions can contribute to specific areas of Superset:
+- SQL Lab panels (left, right, bottom, editor)
+- Custom commands and menu items
+- Status bar components
+- API endpoints and backend functionality
+
+### 🔧 Modern Development Experience
+
+- **CLI tools** for scaffolding, building, and packaging
+- **Hot reloading** during development
+- **TypeScript support** with full type safety
+- **Module Federation** for dynamic loading
+
+### 📦 Simple Distribution
+
+- Package extensions as `.supx` files
+- Upload via REST API or UI
+- Automatic activation and lifecycle management
+- Version compatibility checking
+
+## Getting Started
+
+Ready to build your first extension? Check out our [Getting Started Guide](./getting-started) to:
+
+1. Set up your development environment
+2. Create your first extension
+3. Test it locally
+4. Package and deploy it
+
+## Architecture Overview
+
+Our extension architecture is built on several key principles:
+
+- **Lean Core**: Keep Superset's core minimal and delegate features to extensions
+- **Explicit APIs**: Clear, versioned interfaces for extension interactions
+- **Lazy Loading**: Extensions load only when needed for optimal performance
+- **Security First**: Extensions run with appropriate permissions and sandboxing
+
+Learn more in our [Architecture Documentation](./architecture/overview).
+
+## Current Status
+
+The extension architecture is currently in active development. The initial focus is on SQL Lab extensions, with plans to expand to:
+
+- Dashboard extensions
+- Chart plugins (enhanced from current system)
+- Database connectors
+- Security providers
+
+## Example: Dataset References Extension
+
+See the extension system in action with our Dataset References example, which adds a SQL Lab panel showing:
+
+- Tables referenced in queries
+- Table owners for permission requests  
+- Last available partitions
+- Estimated row counts
+
+## Join the Community
+
+- **Contribute**: Help shape the future of Superset extensions
+- **Share**: Publish your extensions for others to use
+- **Learn**: Explore extensions built by the community
+
+## Quick Links
+
+- [Getting Started Guide](./getting-started)
+- [Extension Architecture](./architecture/overview)
+- [API Reference](./api/frontend)
+- [CLI Documentation](./cli/overview)
+- [Examples](./examples)
+
+---
+
+*The Superset extension architecture is inspired by the successful model of VS Code Extensions, bringing similar flexibility and power to the data exploration domain.*

docs/developer_portal/sidebars.js

@@ -0,0 +1,59 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+module.exports = {
+  developerPortalSidebar: [
+    'index',
+    {
+      type: 'category',
+      label: 'Getting Started',
+      items: [
+        'getting-started/index',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Architecture',
+      items: [
+        'architecture/overview',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'API Reference',
+      items: [
+        'api/frontend',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'CLI',
+      items: [
+        'cli/overview',
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Examples',
+      items: [
+        'examples/index',
+      ],
+    },
+  ],
+};

docs/developer_portal/versions.json

@@ -0,0 +1 @@
+[]

docs/developer_portal_versions.json

@@ -0,0 +1 @@
+[]

docs/docs/configuration/theming.mdx

@@ -13,9 +13,9 @@ apache-superset>=6.0
 Superset now rides on **Ant Design v5's token-based theming**.
 Every Antd token works, plus a handful of Superset-specific ones for charts and dashboard chrome.
 
-## Managing Themes via CRUD Interface
+## Managing Themes via UI
 
-Superset now includes a built-in **Theme Management** interface accessible from the admin menu under **Settings > Themes**.
+Superset includes a built-in **Theme Management** interface accessible from the admin menu under **Settings > Themes**.
 
 ### Creating a New Theme
 
@@ -29,22 +29,38 @@ Superset now includes a built-in **Theme Management** interface accessible from
 
 You can also extend with Superset-specific tokens (documented in the default theme object) before you import.
 
+### System Theme Administration
+
+When `ENABLE_UI_THEME_ADMINISTRATION = True` is configured, administrators can manage system-wide themes directly from the UI:
+
+#### Setting System Themes
+- **System Default Theme**: Click the sun icon on any theme to set it as the system-wide default
+- **System Dark Theme**: Click the moon icon on any theme to set it as the system dark mode theme
+- **Automatic OS Detection**: When both default and dark themes are set, Superset automatically detects and applies the appropriate theme based on OS preferences
+
+#### Managing System Themes
+- System themes are indicated with special badges in the theme list
+- Only administrators with write permissions can modify system theme settings
+- Removing a system theme designation reverts to configuration file defaults
+
 ### Applying Themes to Dashboards
 
 Once created, themes can be applied to individual dashboards:
 - Edit any dashboard and select your custom theme from the theme dropdown
 - Each dashboard can have its own theme, allowing for branded or context-specific styling
 
-## Alternative: Instance-wide Configuration
+## Configuration Options
 
-For system-wide theming, you can configure default themes via Python configuration:
+### Python Configuration
 
-### Setting Default Themes
+Configure theme behavior via `superset_config.py`:
 
 ```python
-# superset_config.py
+# Enable UI-based theme administration for admins
+ENABLE_UI_THEME_ADMINISTRATION = True
 
-# Default theme (light mode)
+# Optional: Set initial default themes via configuration
+# These can be overridden via the UI when ENABLE_UI_THEME_ADMINISTRATION = True
 THEME_DEFAULT = {
     "token": {
         "colorPrimary": "#2893B3",
@@ -53,7 +69,7 @@ THEME_DEFAULT = {
     }
 }
 
-# Dark theme configuration
+# Optional: Dark theme configuration
 THEME_DARK = {
     "algorithm": "dark",
     "token": {
@@ -62,23 +78,28 @@ THEME_DARK = {
     }
 }
 
-# Theme behavior settings
-THEME_SETTINGS = {
-    "enforced": False,          # If True, forces default theme always
-    "allowSwitching": True,     # Allow users to switch between themes
-    "allowOSPreference": True,  # Auto-detect system theme preference
-}
+# To force a single theme on all users, set THEME_DARK = None
+# When both themes are defined (via UI or config):
+# - Users can manually switch between themes
+# - OS preference detection is automatically enabled
 ```
 
-### Copying Themes from CRUD Interface
+### Migration from Configuration to UI
 
-To use a theme created via the CRUD interface as your system default:
+When `ENABLE_UI_THEME_ADMINISTRATION = True`:
 
-1. Navigate to **Settings > Themes** and edit your desired theme
-2. Copy the complete JSON configuration from the theme definition field
-3. Paste it directly into your `superset_config.py` as shown above
+1. System themes set via the UI take precedence over configuration file settings
+2. The UI shows which themes are currently set as system defaults
+3. Administrators can change system themes without restarting Superset
+4. Configuration file themes serve as fallbacks when no UI themes are set
 
-Restart Superset to apply changes.
+### Copying Themes Between Systems
+
+To export a theme for use in configuration files or another instance:
+
+1. Navigate to **Settings > Themes** and click the export icon on your desired theme
+2. Extract the JSON configuration from the exported YAML file
+3. Use this JSON in your `superset_config.py` or import it into another Superset instance
 
 ## Theme Development Workflow
 
@@ -87,8 +108,85 @@ Restart Superset to apply changes.
 3. **Apply**: Assign themes to specific dashboards or configure instance-wide
 4. **Iterate**: Modify theme JSON directly in the CRUD interface or re-import from the theme editor
 
+## Custom Fonts
+
+Superset supports custom fonts through runtime configuration, allowing you to use branded or custom typefaces without rebuilding the application.
+
+### Configuring Custom Fonts
+
+Add font URLs to your `superset_config.py`:
+
+```python
+# Load fonts from Google Fonts, Adobe Fonts, or self-hosted sources
+CUSTOM_FONT_URLS = [
+    "https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap",
+    "https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500&display=swap",
+]
+
+# Update CSP to allow font sources
+TALISMAN_CONFIG = {
+    "content_security_policy": {
+        "font-src": ["'self'", "https://fonts.googleapis.com", "https://fonts.gstatic.com"],
+        "style-src": ["'self'", "'unsafe-inline'", "https://fonts.googleapis.com"],
+    }
+}
+```
+
+### Using Custom Fonts in Themes
+
+Once configured, reference the fonts in your theme configuration:
+
+```python
+THEME_DEFAULT = {
+    "token": {
+        "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
+        "fontFamilyCode": "JetBrains Mono, Monaco, monospace",
+        # ... other theme tokens
+    }
+}
+```
+
+Or in the CRUD interface theme JSON:
+
+```json
+{
+  "token": {
+    "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
+    "fontFamilyCode": "JetBrains Mono, Monaco, monospace"
+  }
+}
+```
+
+### Font Sources
+
+- **Google Fonts**: Free, CDN-hosted fonts with wide variety
+- **Adobe Fonts**: Premium fonts (requires subscription and kit ID)
+- **Self-hosted**: Place font files in `/static/assets/fonts/` and reference via CSS
+
+This feature works with the stock Docker image - no custom build required!
+
 ## Advanced Features
 
-- **System Themes**: Superset includes built-in light and dark themes
+- **System Themes**: Manage system-wide default and dark themes via UI or configuration
 - **Per-Dashboard Theming**: Each dashboard can have its own visual identity
 - **JSON Editor**: Edit theme configurations directly within Superset's interface
+- **Custom Fonts**: Load external fonts via configuration without rebuilding
+- **OS Dark Mode Detection**: Automatically switches themes based on system preferences
+- **Theme Import/Export**: Share themes between instances via YAML files
+
+## API Access
+
+For programmatic theme management, Superset provides REST endpoints:
+
+- `GET /api/v1/theme/` - List all themes
+- `POST /api/v1/theme/` - Create a new theme
+- `PUT /api/v1/theme/{id}` - Update a theme
+- `DELETE /api/v1/theme/{id}` - Delete a theme
+- `PUT /api/v1/theme/{id}/set_system_default` - Set as system default theme (admin only)
+- `PUT /api/v1/theme/{id}/set_system_dark` - Set as system dark theme (admin only)
+- `DELETE /api/v1/theme/unset_system_default` - Remove system default designation
+- `DELETE /api/v1/theme/unset_system_dark` - Remove system dark designation
+- `GET /api/v1/theme/export/` - Export themes as YAML
+- `POST /api/v1/theme/import/` - Import themes from YAML
+
+These endpoints require appropriate permissions and are subject to RBAC controls.

docs/docs/contributing/development.mdx

@@ -120,6 +120,78 @@ docker volume rm superset_db_home
 docker-compose up
 ```
 
+## GitHub Codespaces (Cloud Development)
+
+GitHub Codespaces provides a complete, pre-configured development environment in the cloud. This is ideal for:
+- Quick contributions without local setup
+- Consistent development environments across team members
+- Working from devices that can't run Docker locally
+- Safe experimentation in isolated environments
+
+:::info
+We're grateful to GitHub for providing this excellent cloud development service that makes
+contributing to Apache Superset more accessible to developers worldwide.
+:::
+
+### Getting Started with Codespaces
+
+1. **Create a Codespace**: Use this pre-configured link that sets up everything you need:
+
+   [**Launch Superset Codespace →**](https://github.com/codespaces/new?skip_quickstart=true&machine=standardLinux32gb&repo=39464018&ref=master&devcontainer_path=.devcontainer%2Fdevcontainer.json&geo=UsWest)
+
+   :::caution
+   **Important**: You must select at least the **4 CPU / 16GB RAM** machine type (pre-selected in the link above).
+   Smaller instances will not have sufficient resources to run Superset effectively.
+   :::
+
+2. **Wait for Setup**: The initial setup takes several minutes. The Codespace will:
+   - Build the development container
+   - Install all dependencies
+   - Start all required services (PostgreSQL, Redis, etc.)
+   - Initialize the database with example data
+
+3. **Access Superset**: Once ready, check the **PORTS** tab in VS Code for port `9001`.
+   Click the globe icon to open Superset in your browser.
+   - Default credentials: `admin` / `admin`
+
+### Key Features
+
+- **Auto-reload**: Both Python and TypeScript files auto-refresh on save
+- **Pre-installed Extensions**: VS Code extensions for Python, TypeScript, and database tools
+- **Multiple Instances**: Run multiple Codespaces for different branches/features
+- **SSH Access**: Connect via terminal using `gh cs ssh` or through the GitHub web UI
+- **VS Code Integration**: Works seamlessly with VS Code desktop app
+
+### Managing Codespaces
+
+- **List active Codespaces**: `gh cs list`
+- **SSH into a Codespace**: `gh cs ssh`
+- **Stop a Codespace**: Via GitHub UI or `gh cs stop`
+- **Delete a Codespace**: Via GitHub UI or `gh cs delete`
+
+### Debugging and Logs
+
+Since Codespaces uses `docker-compose-light.yml`, you can monitor all services:
+
+```bash
+# Stream logs from all services
+docker compose -f docker-compose-light.yml logs -f
+
+# Stream logs from a specific service
+docker compose -f docker-compose-light.yml logs -f superset
+
+# View last 100 lines and follow
+docker compose -f docker-compose-light.yml logs --tail=100 -f
+
+# List all running services
+docker compose -f docker-compose-light.yml ps
+```
+
+:::tip
+Codespaces automatically stop after 30 minutes of inactivity to save resources.
+Your work is preserved and you can restart anytime.
+:::
+
 ## Installing Development Tools
 
 :::note
@@ -349,14 +421,6 @@ Then make sure you run your WSGI server using the right worker type:
 gunicorn "superset.app:create_app()" -k "geventwebsocket.gunicorn.workers.GeventWebSocketWorker" -b 127.0.0.1:8088 --reload
 ```
 
-You can log anything to the browser console, including objects:
-
-```python
-from superset import app
-app.logger.error('An exception occurred!')
-app.logger.info(form_data)
-```
-
 ### Frontend
 
 Frontend assets (TypeScript, JavaScript, CSS, and images) must be compiled in order to properly display the web UI. The `superset-frontend` directory contains all NPM-managed frontend assets. Note that for some legacy pages there are additional frontend assets bundled with Flask-Appbuilder (e.g. jQuery and bootstrap). These are not managed by NPM and may be phased out in the future.

docs/docs/security/cves.mdx

@@ -2,6 +2,20 @@
 title: CVEs fixed by release
 sidebar_position: 2
 ---
+#### Version 5.0.0
+
+| CVE            | Title                                                                              | Affected |
+|:---------------|:-----------------------------------------------------------------------------------|---------:|
+| CVE-2025-55673 | Exposure of Sensitive Information to an Unauthorized Actor                         |  < 5.0.0 |
+| CVE-2025-55674 | Improper Neutralization of Special Elements used in an SQL Command                 |  < 5.0.0 |
+| CVE-2025-55675 | Improper Access Control leading to Information Disclosure                          |  < 5.0.0 |
+
+#### Version 4.1.3
+
+| CVE            | Title                                                                              | Affected |
+|:---------------|:-----------------------------------------------------------------------------------|---------:|
+| CVE-2025-55672 | Improper Neutralization of Input During Web Page Generation                        |  < 4.1.3 |
+
 #### Version 4.1.2
 
 | CVE            | Title                                                                              | Affected |

docs/docusaurus.config.ts

@@ -20,16 +20,125 @@
 import type { Config } from '@docusaurus/types';
 import type { Options, ThemeConfig } from '@docusaurus/preset-classic';
 import { themes } from 'prism-react-renderer';
+import remarkImportPartial from 'remark-import-partial';
+import * as fs from 'fs';
+import * as path from 'path';
 
 const { github: lightCodeTheme, vsDark: darkCodeTheme } = themes;
 
+// Load version configuration from external file
+const versionsConfigPath = path.join(__dirname, 'versions-config.json');
+const versionsConfig = JSON.parse(fs.readFileSync(versionsConfigPath, 'utf8'));
+
+// Build plugins array dynamically based on disabled flags
+const dynamicPlugins = [];
+
+// Add components plugin if not disabled
+if (!versionsConfig.components.disabled) {
+  dynamicPlugins.push([
+    '@docusaurus/plugin-content-docs',
+    {
+      id: 'components',
+      path: 'components',
+      routeBasePath: 'components',
+      sidebarPath: require.resolve('./sidebarComponents.js'),
+      editUrl:
+        'https://github.com/apache/superset/edit/master/docs/components',
+      remarkPlugins: [remarkImportPartial],
+      docItemComponent: '@theme/DocItem',
+      includeCurrentVersion: versionsConfig.components.includeCurrentVersion,
+      lastVersion: versionsConfig.components.lastVersion,
+      onlyIncludeVersions: versionsConfig.components.onlyIncludeVersions,
+      versions: versionsConfig.components.versions,
+      disableVersioning: false,
+      showLastUpdateAuthor: true,
+      showLastUpdateTime: true,
+    },
+  ]);
+}
+
+// Add developer_portal plugin if not disabled
+if (!versionsConfig.developer_portal.disabled) {
+  dynamicPlugins.push([
+    '@docusaurus/plugin-content-docs',
+    {
+      id: 'developer_portal',
+      path: 'developer_portal',
+      routeBasePath: 'developer_portal',
+      sidebarPath: require.resolve('./sidebarTutorials.js'),
+      editUrl:
+        'https://github.com/apache/superset/edit/master/docs/developer_portal',
+      remarkPlugins: [remarkImportPartial],
+      docItemComponent: '@theme/DocItem',
+      includeCurrentVersion: versionsConfig.developer_portal.includeCurrentVersion,
+      lastVersion: versionsConfig.developer_portal.lastVersion,
+      onlyIncludeVersions: versionsConfig.developer_portal.onlyIncludeVersions,
+      versions: versionsConfig.developer_portal.versions,
+      disableVersioning: false,
+      showLastUpdateAuthor: true,
+      showLastUpdateTime: true,
+    },
+  ]);
+}
+
+// Build navbar items dynamically based on disabled flags
+const dynamicNavbarItems = [];
+
+// Add Component Playground navbar item if not disabled
+if (!versionsConfig.components.disabled) {
+  dynamicNavbarItems.push({
+    label: 'Component Playground',
+    to: '/components',
+    items: [
+      {
+        label: 'Introduction',
+        to: '/components',
+      },
+      {
+        label: 'UI Components',
+        to: '/components/ui-components/button',
+      },
+      {
+        label: 'Chart Components',
+        to: '/components/chart-components/bar-chart',
+      },
+      {
+        label: 'Layout Components',
+        to: '/components/layout-components/grid',
+      },
+    ],
+  });
+}
+
+// Add Developer Portal navbar item if not disabled
+if (!versionsConfig.developer_portal.disabled) {
+  dynamicNavbarItems.push({
+    label: 'Developer Portal',
+    position: 'left',
+    items: [
+      {
+        type: 'doc',
+        docsPluginId: 'developer_portal',
+        docId: 'index',
+        label: 'Introduction',
+      },
+      {
+        type: 'doc',
+        docsPluginId: 'developer_portal',
+        docId: 'getting-started/index',
+        label: 'Getting Started',
+      },
+    ],
+  });
+}
+
 const config: Config = {
   title: 'Superset',
   tagline:
     'Apache Superset is a modern data exploration and visualization platform',
   url: 'https://superset.apache.org',
   baseUrl: '/',
-  onBrokenLinks: 'throw',
+  onBrokenLinks: 'warn',
   onBrokenMarkdownLinks: 'throw',
   markdown: {
     mermaid: true,
@@ -39,6 +148,7 @@ const config: Config = {
   projectName: 'superset',
   themes: ['@saucelabs/theme-github-codeblock', '@docusaurus/theme-mermaid'],
   plugins: [
+    require.resolve('./src/webpack.extend.ts'),
     [
       'docusaurus-plugin-less',
       {
@@ -47,11 +157,10 @@ const config: Config = {
         },
       },
     ],
+    ...dynamicPlugins,
     [
       '@docusaurus/plugin-client-redirects',
       {
-        fromExtensions: ['html', 'htm'],
-        toExtensions: ['exe', 'zip'],
         redirects: [
           {
             to: '/docs/installation/docker-compose',
@@ -210,6 +319,13 @@ const config: Config = {
             }
             return `https://github.com/apache/superset/edit/master/docs/${versionDocsDirPath}/${docPath}`;
           },
+          includeCurrentVersion: versionsConfig.docs.includeCurrentVersion,
+          lastVersion: versionsConfig.docs.lastVersion,  // Make 'next' the default
+          onlyIncludeVersions: versionsConfig.docs.onlyIncludeVersions,
+          versions: versionsConfig.docs.versions,
+          disableVersioning: false,
+          showLastUpdateAuthor: true,
+          showLastUpdateTime: true,
         },
         blog: {
           showReadingTime: true,
@@ -235,6 +351,13 @@ const config: Config = {
       apiKey: 'd0d22810f2e9b614ffac3a73b26891fe',
       indexName: 'superset-apache',
     },
+    mermaid: {
+      theme: { light: 'neutral', dark: 'dark' },
+      options: {
+        // Any Mermaid config options go here...
+        maxTextSize: 100000,
+      },
+    },
     navbar: {
       logo: {
         alt: 'Superset Logo',
@@ -244,20 +367,22 @@ const config: Config = {
       items: [
         {
           label: 'Documentation',
-          to: '/docs/intro',
+          position: 'left',
           items: [
             {
+              type: 'doc',
+              docId: 'intro',
               label: 'Getting Started',
-              to: '/docs/intro',
             },
             {
+              type: 'doc',
+              docId: 'faq',
               label: 'FAQ',
-              to: '/docs/faq',
             },
           ],
         },
         {
-          label: 'Community',
+          label: 'Community Resources',
           to: '/community',
           items: [
             {
@@ -282,6 +407,7 @@ const config: Config = {
             },
           ],
         },
+        ...dynamicNavbarItems,
         {
           href: '/docs/intro',
           position: 'right',
@@ -336,7 +462,6 @@ const config: Config = {
     //   src: 'https://www.bugherd.com/sidebarv2.js?apikey=enilpiu7bgexxsnoqfjtxa',
     //   async: true,
     // },
-    '/script/matomo.js',
     {
       src: 'https://widget.kapa.ai/kapa-widget.bundle.js',
       async: true,

docs/eslint.config.js

@@ -28,6 +28,9 @@ const globals = require('globals');
 const { defineConfig, globalIgnores } = require('eslint/config');
 
 module.exports = defineConfig([
+  {
+    files: ['**/*.{js,jsx,ts,tsx}'],
+  },
   globalIgnores(['build/**/*', '.docusaurus/**/*', 'node_modules/**/*']),
   js.configs.recommended,
   ...ts.configs.recommended,
@@ -36,7 +39,7 @@ module.exports = defineConfig([
     files: ['eslint.config.js'],
     rules: {
       '@typescript-eslint/no-require-imports': 'off',
-    }
+    },
   },
   {
     languageOptions: {
@@ -68,5 +71,5 @@ module.exports = defineConfig([
         version: 'detect',
       },
     },
-  }
-])
+  },
+]);

docs/package.json

@@ -6,7 +6,8 @@
   "scripts": {
     "docusaurus": "docusaurus",
     "_init": "cat src/intro_header.txt ../README.md > docs/intro.md",
-    "start": "yarn run _init && docusaurus start",
+    "start": "yarn run _init && NODE_ENV=development docusaurus start",
+    "stop": "pkill -f 'docusaurus start' || echo 'No docusaurus server running'",
     "build": "yarn run _init && DEBUG=docusaurus:* docusaurus build",
     "swizzle": "docusaurus swizzle",
     "deploy": "docusaurus deploy",
@@ -15,44 +16,73 @@
     "write-translations": "docusaurus write-translations",
     "write-heading-ids": "docusaurus write-heading-ids",
     "typecheck": "tsc",
-    "eslint": "eslint . --ext .js,.jsx,.ts,.tsx"
+    "eslint": "eslint .",
+    "version:add": "node scripts/manage-versions.mjs add",
+    "version:remove": "node scripts/manage-versions.mjs remove",
+    "version:add:docs": "node scripts/manage-versions.mjs add docs",
+    "version:add:developer_portal": "node scripts/manage-versions.mjs add developer_portal",
+    "version:add:components": "node scripts/manage-versions.mjs add components",
+    "version:remove:docs": "node scripts/manage-versions.mjs remove docs",
+    "version:remove:developer_portal": "node scripts/manage-versions.mjs remove developer_portal",
+    "version:remove:components": "node scripts/manage-versions.mjs remove components"
   },
   "dependencies": {
     "@ant-design/icons": "^6.0.0",
     "@docusaurus/core": "3.8.1",
     "@docusaurus/plugin-client-redirects": "3.8.1",
     "@docusaurus/preset-classic": "3.8.1",
-    "@docusaurus/theme-mermaid": "3.8.1",
+    "@docusaurus/theme-mermaid": "^3.8.1",
+    "@emotion/core": "^10.0.27",
+    "@emotion/react": "^11.13.3",
     "@emotion/styled": "^10.0.27",
+    "@mdx-js/react": "^3.1.0",
     "@saucelabs/theme-github-codeblock": "^0.3.0",
-    "@superset-ui/style": "^0.14.23",
-    "antd": "^5.26.3",
+    "@storybook/addon-docs": "^8.6.11",
+    "@storybook/blocks": "^8.6.11",
+    "@storybook/channels": "^8.6.11",
+    "@storybook/client-logger": "^8.6.11",
+    "@storybook/components": "^8.6.11",
+    "@storybook/core": "^8.6.11",
+    "@storybook/core-events": "^8.6.11",
+    "@storybook/csf": "^0.1.13",
+    "@storybook/docs-tools": "^8.6.11",
+    "@storybook/preview-api": "^8.6.11",
+    "@storybook/theming": "^8.6.11",
+    "@superset-ui/core": "^0.20.4",
+    "antd": "^5.26.7",
+    "caniuse-lite": "^1.0.30001707",
     "docusaurus-plugin-less": "^2.0.2",
-    "less": "^4.3.0",
+    "json-bigint": "^1.0.0",
+    "less": "^4.4.0",
     "less-loader": "^12.3.0",
     "prism-react-renderer": "^2.4.1",
     "react": "^18.3.1",
     "react-dom": "^18.3.1",
     "react-github-btn": "^1.4.0",
     "react-svg-pan-zoom": "^3.13.1",
-    "swagger-ui-react": "^5.26.0"
+    "remark-import-partial": "^0.0.2",
+    "reselect": "^5.1.1",
+    "storybook": "^8.6.11",
+    "swagger-ui-react": "^5.27.1",
+    "tinycolor2": "^1.4.2",
+    "ts-loader": "^9.5.2"
   },
   "devDependencies": {
     "@docusaurus/module-type-aliases": "^3.8.1",
     "@docusaurus/tsconfig": "^3.8.1",
-    "@eslint/js": "^9.31.0",
+    "@eslint/js": "^9.32.0",
     "@types/react": "^19.1.8",
     "@typescript-eslint/eslint-plugin": "^8.37.0",
     "@typescript-eslint/parser": "^8.37.0",
-    "eslint": "^9.31.0",
-    "eslint-config-prettier": "^10.1.5",
-    "eslint-plugin-prettier": "^5.5.1",
+    "eslint": "^9.32.0",
+    "eslint-config-prettier": "^10.1.8",
+    "eslint-plugin-prettier": "^5.5.3",
     "eslint-plugin-react": "^7.37.5",
     "globals": "^16.3.0",
     "prettier": "^3.6.2",
     "typescript": "~5.8.3",
-    "typescript-eslint": "^8.37.0",
-    "webpack": "^5.99.9"
+    "typescript-eslint": "^8.39.0",
+    "webpack": "^5.101.0"
   },
   "browserslist": {
     "production": [

docs/scripts/manage-versions.mjs

@@ -0,0 +1,242 @@
+#!/usr/bin/env node
+
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import fs from 'fs';
+import path from 'path';
+import { execSync } from 'child_process';
+import { fileURLToPath } from 'url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+const CONFIG_FILE = path.join(__dirname, '..', 'versions-config.json');
+
+// Parse command line arguments
+const args = process.argv.slice(2);
+const command = args[0]; // 'add' or 'remove'
+const section = args[1]; // 'docs', 'developer_portal', or 'components'
+const version = args[2]; // version string like '1.2.0'
+
+function loadConfig() {
+  return JSON.parse(fs.readFileSync(CONFIG_FILE, 'utf8'));
+}
+
+function saveConfig(config) {
+  fs.writeFileSync(CONFIG_FILE, JSON.stringify(config, null, 2) + '\n');
+}
+
+function fixVersionedImports(version) {
+  const versionedDocsPath = path.join(__dirname, '..', 'versioned_docs', `version-${version}`);
+
+  // Files that need import path fixes
+  const filesToFix = [
+    'contributing/resources.mdx',
+    'configuration/country-map-tools.mdx'
+  ];
+
+  console.log(`  Fixing relative imports in versioned docs...`);
+
+  filesToFix.forEach(filePath => {
+    const fullPath = path.join(versionedDocsPath, filePath);
+    if (fs.existsSync(fullPath)) {
+      let content = fs.readFileSync(fullPath, 'utf8');
+
+      // Fix imports that go up two directories to go up three instead
+      content = content.replace(
+        /from ['"]\.\.\/\.\.\/src\//g,
+        "from '../../../src/"
+      );
+      content = content.replace(
+        /from ['"]\.\.\/\.\.\/data\//g,
+        "from '../../../data/"
+      );
+
+      fs.writeFileSync(fullPath, content);
+      console.log(`    Fixed imports in ${filePath}`);
+    }
+  });
+}
+
+function addVersion(section, version) {
+  const config = loadConfig();
+
+  if (!config[section]) {
+    console.error(`Section '${section}' not found in config`);
+    process.exit(1);
+  }
+
+  // Check if version already exists
+  if (config[section].onlyIncludeVersions.includes(version)) {
+    console.error(`Version ${version} already exists in ${section}`);
+    process.exit(1);
+  }
+
+  console.log(`Creating version ${version} for ${section}...`);
+
+  // Run Docusaurus version command
+  const docusaurusCommand = section === 'docs'
+    ? `yarn docusaurus docs:version ${version}`
+    : `yarn docusaurus docs:version:${section} ${version}`;
+
+  try {
+    execSync(docusaurusCommand, { stdio: 'inherit' });
+  } catch (error) {
+    console.error(`Failed to create version: ${error.message}`);
+    process.exit(1);
+  }
+
+  // Fix relative imports in versioned docs (for main docs section only)
+  if (section === 'docs') {
+    fixVersionedImports(version);
+  }
+
+  // Update config
+  // Add to onlyIncludeVersions array (after 'current')
+  const versionIndex = config[section].onlyIncludeVersions.indexOf('current') + 1;
+  config[section].onlyIncludeVersions.splice(versionIndex, 0, version);
+
+  // Add version metadata
+  const versionPath = section === 'docs' ? version : version;
+  config[section].versions[version] = {
+    label: version,
+    path: versionPath,
+    banner: 'none'
+  };
+
+  // Optionally update lastVersion if this is the first non-current version
+  if (config[section].onlyIncludeVersions.length === 2) {
+    config[section].lastVersion = version;
+  }
+
+  saveConfig(config);
+  console.log(`✅ Version ${version} added successfully to ${section}`);
+  console.log(`📝 Updated versions-config.json`);
+}
+
+function removeVersion(section, version) {
+  const config = loadConfig();
+
+  if (!config[section]) {
+    console.error(`Section '${section}' not found in config`);
+    process.exit(1);
+  }
+
+  if (version === 'current') {
+    console.error(`Cannot remove 'current' version`);
+    process.exit(1);
+  }
+
+  if (!config[section].onlyIncludeVersions.includes(version)) {
+    console.error(`Version ${version} not found in ${section}`);
+    process.exit(1);
+  }
+
+  console.log(`Removing version ${version} from ${section}...`);
+
+  // Determine file paths based on section
+  const versionedDocsDir = section === 'docs'
+    ? `versioned_docs/version-${version}`
+    : `${section}_versioned_docs/version-${version}`;
+
+  const versionedSidebarsFile = section === 'docs'
+    ? `versioned_sidebars/version-${version}-sidebars.json`
+    : `${section}_versioned_sidebars/version-${version}-sidebars.json`;
+
+  // Remove versioned files
+  const docsPath = path.join(__dirname, '..', versionedDocsDir);
+  const sidebarsPath = path.join(__dirname, '..', versionedSidebarsFile);
+
+  if (fs.existsSync(docsPath)) {
+    fs.rmSync(docsPath, { recursive: true });
+    console.log(`  Removed ${versionedDocsDir}`);
+  }
+
+  if (fs.existsSync(sidebarsPath)) {
+    fs.unlinkSync(sidebarsPath);
+    console.log(`  Removed ${versionedSidebarsFile}`);
+  }
+
+  // Update versions.json file
+  const versionsJsonFile = section === 'docs'
+    ? 'versions.json'
+    : `${section}_versions.json`;
+  const versionsJsonPath = path.join(__dirname, '..', versionsJsonFile);
+
+  if (fs.existsSync(versionsJsonPath)) {
+    const versions = JSON.parse(fs.readFileSync(versionsJsonPath, 'utf8'));
+    const versionIndex = versions.indexOf(version);
+    if (versionIndex > -1) {
+      versions.splice(versionIndex, 1);
+      fs.writeFileSync(versionsJsonPath, JSON.stringify(versions, null, 2) + '\n');
+      console.log(`  Updated ${versionsJsonFile}`);
+    }
+  }
+
+  // Update config
+  const versionIndex = config[section].onlyIncludeVersions.indexOf(version);
+  config[section].onlyIncludeVersions.splice(versionIndex, 1);
+  delete config[section].versions[version];
+
+  // Update lastVersion if needed
+  if (config[section].lastVersion === version) {
+    // Set to the next available version or 'current'
+    const remainingVersions = config[section].onlyIncludeVersions.filter(v => v !== 'current');
+    config[section].lastVersion = remainingVersions.length > 0 ? remainingVersions[0] : 'current';
+    console.log(`  Updated lastVersion to ${config[section].lastVersion}`);
+  }
+
+  saveConfig(config);
+  console.log(`✅ Version ${version} removed successfully from ${section}`);
+  console.log(`📝 Updated versions-config.json`);
+}
+
+function printUsage() {
+  console.log(`
+Usage:
+  node scripts/manage-versions.js add <section> <version>
+  node scripts/manage-versions.js remove <section> <version>
+
+Where:
+  - section: 'docs', 'developer_portal', or 'components'
+  - version: version string (e.g., '1.2.0', '2.0.0')
+
+Examples:
+  node scripts/manage-versions.js add docs 2.0.0
+  node scripts/manage-versions.js add developer_portal 1.3.0
+  node scripts/manage-versions.js remove components 1.0.0
+`);
+}
+
+// Main execution
+if (!command || !section || !version) {
+  printUsage();
+  process.exit(1);
+}
+
+if (command === 'add') {
+  addVersion(section, version);
+} else if (command === 'remove') {
+  removeVersion(section, version);
+} else {
+  console.error(`Unknown command: ${command}`);
+  printUsage();
+  process.exit(1);
+}

docs/sidebarComponents.js

@@ -0,0 +1,68 @@
+/* eslint-env node */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+// @ts-check
+
+/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */
+const sidebars = {
+  // By default, Docusaurus generates a sidebar from the docs folder structure
+  //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
+
+  // But we're not doing that.
+  ComponentSidebar: [
+    {
+      type: 'doc',
+      label: 'Introduction',
+      id: 'index',
+    },
+    {
+      type: 'category',
+      label: 'UI Components',
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'ui-components',
+        },
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Chart Components',
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'chart-components',
+        },
+      ],
+    },
+    {
+      type: 'category',
+      label: 'Layout Components',
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'layout-components',
+        },
+      ],
+    },
+  ],
+};
+
+module.exports = sidebars;

docs/sidebarTutorials.js

@@ -0,0 +1,48 @@
+/* eslint-env node */
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+// @ts-check
+
+/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */
+const sidebars = {
+  // By default, Docusaurus generates a sidebar from the docs folder structure
+  //tutorialSidebar: [{type: 'autogenerated', dirName: '.'}],
+
+  // But we're not doing that.
+  TutorialsSidebar: [
+    {
+      type: 'doc',
+      label: 'Introduction',
+      id: 'index',
+    },
+    {
+      type: 'category',
+      label: 'Getting Started',
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'getting-started',
+        },
+      ],
+    },
+  ],
+};
+
+module.exports = sidebars;

docs/src/components/Button.jsx

@@ -0,0 +1,23 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+// Re-export the Button component as a default export
+import { Button } from '../../../superset-frontend/packages/superset-ui-core/src/components/Button';
+
+export default Button;

docs/src/components/StorybookWrapper.jsx

@@ -0,0 +1,121 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import React from 'react';
+import { supersetTheme, ThemeProvider } from '@superset-ui/core';
+
+// A simple component to display a story example
+export function StoryExample({ component: Component, props = {} }) {
+  return (
+    <ThemeProvider theme={supersetTheme}>
+      <div
+        className="storybook-example"
+        style={{
+          border: '1px solid #e8e8e8',
+          borderRadius: '4px',
+          padding: '20px',
+          marginBottom: '20px',
+        }}
+      >
+        {Component && <Component {...props} />}
+      </div>
+    </ThemeProvider>
+  );
+}
+
+// A simple component to display a story with controls
+export function StoryWithControls({
+  component: Component,
+  props = {},
+  controls = [],
+}) {
+  const [stateProps, setStateProps] = React.useState(props);
+
+  const updateProp = (key, value) => {
+    setStateProps(prev => ({
+      ...prev,
+      [key]: value,
+    }));
+  };
+
+  return (
+    <ThemeProvider theme={supersetTheme}>
+      <div className="storybook-with-controls">
+        <div
+          className="storybook-example"
+          style={{
+            border: '1px solid #e8e8e8',
+            borderRadius: '4px',
+            padding: '20px',
+            marginBottom: '20px',
+          }}
+        >
+          {Component && <Component {...stateProps} />}
+        </div>
+
+        {controls.length > 0 && (
+          <div
+            className="storybook-controls"
+            style={{
+              border: '1px solid #e8e8e8',
+              borderRadius: '4px',
+              padding: '20px',
+              marginBottom: '20px',
+            }}
+          >
+            <h4>Controls</h4>
+            {controls.map(control => (
+              <div key={control.name} style={{ marginBottom: '10px' }}>
+                <label style={{ display: 'block', marginBottom: '5px' }}>
+                  {control.label || control.name}:
+                </label>
+                {control.type === 'select' ? (
+                  <select
+                    value={stateProps[control.name]}
+                    onChange={e => updateProp(control.name, e.target.value)}
+                    style={{ width: '100%', padding: '5px' }}
+                  >
+                    {control.options.map(option => (
+                      <option key={option} value={option}>
+                        {option}
+                      </option>
+                    ))}
+                  </select>
+                ) : control.type === 'boolean' ? (
+                  <input
+                    type="checkbox"
+                    checked={stateProps[control.name]}
+                    onChange={e => updateProp(control.name, e.target.checked)}
+                  />
+                ) : (
+                  <input
+                    type="text"
+                    value={stateProps[control.name]}
+                    onChange={e => updateProp(control.name, e.target.value)}
+                    style={{ width: '100%', padding: '5px' }}
+                  />
+                )}
+              </div>
+            ))}
+          </div>
+        )}
+      </div>
+    </ThemeProvider>
+  );
+}

docs/src/pages/index.tsx

@@ -460,15 +460,23 @@ export default function Home(): JSX.Element {
   const changeToDark = () => {
     const navbar = document.body.querySelector('.navbar');
     const logo = document.body.querySelector('.navbar__logo img');
-    navbar.classList.add('navbar--dark');
-    logo.setAttribute('src', '/img/superset-logo-horiz-dark.svg');
+    if (navbar) {
+      navbar.classList.add('navbar--dark');
+    }
+    if (logo) {
+      logo.setAttribute('src', '/img/superset-logo-horiz-dark.svg');
+    }
   };
 
   const changeToLight = () => {
     const navbar = document.body.querySelector('.navbar');
     const logo = document.body.querySelector('.navbar__logo img');
-    navbar.classList.remove('navbar--dark');
-    logo.setAttribute('src', '/img/superset-logo-horiz.svg');
+    if (navbar) {
+      navbar.classList.remove('navbar--dark');
+    }
+    if (logo) {
+      logo.setAttribute('src', '/img/superset-logo-horiz.svg');
+    }
   };
 
   // Set up dark <-> light navbar change
@@ -476,7 +484,9 @@ export default function Home(): JSX.Element {
     changeToDark();
 
     const navbarToggle = document.body.querySelector('.navbar__toggle');
-    navbarToggle.addEventListener('click', () => changeToLight());
+    if (navbarToggle) {
+      navbarToggle.addEventListener('click', () => changeToLight());
+    }
 
     const scrollListener = () => {
       if (window.scrollY > 0) {

docs/src/styles/custom.css

@@ -45,6 +45,60 @@ ul.dropdown__menu svg {
   display: none;
 }
 
+/* Consistent dropdown styling for navbar */
+.navbar__item.dropdown .dropdown__menu {
+  background-color: white;
+  border: 1px solid rgba(0, 0, 0, 0.1);
+  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.1);
+}
+
+.navbar__item.dropdown .dropdown__link {
+  color: #1c1e21 !important;
+  background-color: transparent !important;
+  border-radius: 0 !important;
+  padding: 0.5rem 1rem !important;
+  display: block !important;
+}
+
+.navbar__item.dropdown .dropdown__link:hover {
+  background-color: #f5f5f5 !important;
+  color: #1c1e21 !important;
+  text-decoration: none !important;
+}
+
+/* Remove the blue box styling for doc links in dropdowns */
+.navbar__item.dropdown .dropdown__link--active {
+  background-color: transparent !important;
+  color: #1c1e21 !important;
+}
+
+.navbar__item.dropdown .dropdown__link--active:hover {
+  background-color: #f5f5f5 !important;
+}
+
+/* Dark mode support */
+[data-theme='dark'] .navbar__item.dropdown .dropdown__menu {
+  background-color: #242526;
+  border: 1px solid rgba(255, 255, 255, 0.1);
+}
+
+[data-theme='dark'] .navbar__item.dropdown .dropdown__link {
+  color: #f5f6f7 !important;
+}
+
+[data-theme='dark'] .navbar__item.dropdown .dropdown__link:hover {
+  background-color: #3a3b3c !important;
+  color: #f5f6f7 !important;
+}
+
+[data-theme='dark'] .navbar__item.dropdown .dropdown__link--active {
+  color: #f5f6f7 !important;
+}
+
+[data-theme='dark'] .navbar__item.dropdown .dropdown__link--active:hover {
+  background-color: #3a3b3c !important;
+}
+
 :root {
   --ifm-color-primary: #20a7c9;
   --ifm-color-primary-dark: #1985a0;

docs/src/theme/DocVersionBadge/index.js

@@ -0,0 +1,119 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import React from 'react';
+import {
+  useActivePlugin,
+  useDocsVersion,
+  useVersions,
+} from '@docusaurus/plugin-content-docs/client';
+import { useLocation } from '@docusaurus/router';
+import { useDocsPreferredVersion } from '@docusaurus/theme-common';
+import { Dropdown } from 'antd';
+import { DownOutlined } from '@ant-design/icons';
+
+import styles from './styles.module.css';
+
+export default function DocVersionBadge() {
+  const activePlugin = useActivePlugin();
+  const { pathname } = useLocation();
+  const pluginId = activePlugin?.pluginId;
+  const [versionedPath, setVersionedPath] = React.useState('');
+
+  // Show version selector for all versioned sections
+  const isVersioned = [
+    'default',  // main docs
+    'components',
+    'tutorials',
+    'developer_portal',
+  ].includes(pluginId);
+
+  const { preferredVersion } = useDocsPreferredVersion(pluginId);
+  const versions = useVersions(pluginId);
+  const version = useDocsVersion();
+
+  // Extract the current page path relative to the version
+  React.useEffect(() => {
+    if (!pathname || !version || !pluginId) return;
+
+    let relativePath = '';
+    const basePath = pluginId === 'default' ? '/docs' : `/${pluginId}`;
+
+    // Handle different version path patterns
+    if (pathname.includes(basePath)) {
+      // Extract the part after the base path
+      const parts = pathname.split(basePath);
+      if (parts.length > 1) {
+        const afterBase = parts[1];
+        // For versioned paths, remove the version segment
+        if (afterBase.startsWith('/')) {
+          const segments = afterBase.substring(1).split('/');
+          // Check if first segment is a version (e.g., "1.1.0", "next")
+          if (segments[0] && (segments[0].match(/^\d+\.\d+\.\d+$/) || segments[0] === 'next')) {
+            // Skip the version segment
+            relativePath = segments.length > 1 ? '/' + segments.slice(1).join('/') : '';
+          } else {
+            // No version in path (e.g., /docs/intro for current version with empty path)
+            relativePath = afterBase;
+          }
+        }
+      }
+    }
+
+    setVersionedPath(relativePath);
+  }, [pathname, version, pluginId]);
+
+  // Create dropdown items for version selection
+  const items = versions.map(v => {
+    // Construct the URL for this version, preserving the current page
+    // v.path contains the full path including base, e.g., "/docs/1.1.0" or "/docs"
+    let versionUrl = v.path;
+
+    if (versionedPath) {
+      // Append the current page path to the version base
+      versionUrl = v.path + versionedPath;
+    }
+
+    return {
+      key: v.name,
+      label: (
+        <a href={versionUrl}>
+          {v.label}
+          {v.name === version.name && ' (current)'}
+          {v.name === preferredVersion?.name && ' (preferred)'}
+        </a>
+      ),
+    };
+  });
+
+  if (!isVersioned) {
+    return null;
+  }
+
+  return (
+    <span className={styles.versionBadge}>
+      Version:{' '}
+      <Dropdown menu={{ items }} trigger={['click']}>
+        <a onClick={e => e.preventDefault()} className={styles.versionSelector}>
+          {version.label} <DownOutlined />
+        </a>
+      </Dropdown>
+    </span>
+  );
+}

docs/src/theme/DocVersionBadge/styles.module.css

@@ -0,0 +1,42 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+.versionBadge {
+  display: inline-flex;
+  align-items: center;
+  font-size: 0.8rem;
+  font-weight: 500;
+  color: var(--ifm-color-emphasis-700);
+  background-color: var(--ifm-color-emphasis-200);
+  border-radius: 0.5rem;
+  padding: 0.2rem 0.5rem;
+  margin-right: 0.5rem;
+}
+
+.versionSelector {
+  cursor: pointer;
+  color: var(--ifm-color-primary);
+  font-weight: 500;
+  margin-left: 0.25rem;
+}
+
+.versionSelector:hover {
+  text-decoration: none;
+  color: var(--ifm-color-primary-darker);
+}

docs/src/theme/DocVersionBanner/index.js

@@ -0,0 +1,121 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import React, { useState, useEffect } from 'react';
+import DocVersionBanner from '@theme-original/DocVersionBanner';
+import {
+  useActivePlugin,
+  useDocsVersion,
+  useVersions,
+} from '@docusaurus/plugin-content-docs/client';
+import { useLocation } from '@docusaurus/router';
+import { useDocsPreferredVersion } from '@docusaurus/theme-common';
+import { Dropdown } from 'antd';
+import { DownOutlined } from '@ant-design/icons';
+
+import styles from './styles.module.css';
+
+export default function DocVersionBannerWrapper(props) {
+  const activePlugin = useActivePlugin();
+  const { pathname } = useLocation();
+  const pluginId = activePlugin?.pluginId;
+  const [versionedPath, setVersionedPath] = useState('');
+
+  // Only show version selector for tutorials
+  // Main docs, components, and developer_portal use the DocVersionBadge component instead
+  const isVersioned = pluginId && ['tutorials'].includes(pluginId);
+
+  const { preferredVersion } = useDocsPreferredVersion(pluginId);
+  const versions = useVersions(pluginId);
+  const version = useDocsVersion();
+
+  // Early return if required data is not available
+  if (!isVersioned || !versions || !version) {
+    return <DocVersionBanner {...props} />;
+  }
+
+  // Extract the current page path relative to the version
+  useEffect(() => {
+    if (!pathname || !version || !pluginId) return;
+
+    let relativePath = '';
+
+    // Handle different version path patterns
+    if (pathname.includes(`/${pluginId}/`)) {
+      // Extract the part after the version
+      // Example: /components/1.1.0/ui-components/button -> /ui-components/button
+      const parts = pathname.split(`/${pluginId}/`);
+      if (parts.length > 1) {
+        const afterPluginId = parts[1];
+        // Find where the version part ends
+        const versionParts = afterPluginId.split('/');
+        if (versionParts.length > 1) {
+          // Remove the version part and join the rest
+          relativePath = '/' + versionParts.slice(1).join('/');
+        }
+      }
+    }
+
+    setVersionedPath(relativePath);
+  }, [pathname, version, pluginId]);
+
+  // Create dropdown items for version selection
+  const items = versions.map(v => {
+    // Construct the URL for this version, preserving the current page
+    // v.path is the version-specific path like "1.0.0" or "next"
+    let versionUrl = v.path;
+
+    if (versionedPath) {
+      // Construct the full URL with the version and the current page path
+      versionUrl = v.path + versionedPath;
+    }
+
+    return {
+      key: v.name,
+      label: (
+        <a href={versionUrl}>
+          {v.label}
+          {v.name === version.name && ' (current)'}
+          {v.name === preferredVersion?.name && ' (preferred)'}
+        </a>
+      ),
+    };
+  });
+
+  return (
+    <>
+      <DocVersionBanner {...props} />
+      {isVersioned && (
+        <div className={styles.versionBanner}>
+          <div className={styles.versionContainer}>
+            <span className={styles.versionLabel}>Version:</span>
+            <Dropdown menu={{ items }} trigger={['click']}>
+              <a
+                onClick={e => e.preventDefault()}
+                className={styles.versionSelector}
+              >
+                {version.label} <DownOutlined />
+              </a>
+            </Dropdown>
+          </div>
+        </div>
+      )}
+    </>
+  );
+}

docs/src/theme/DocVersionBanner/styles.module.css

@@ -0,0 +1,49 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+.versionBanner {
+  background-color: var(--ifm-color-emphasis-100);
+  padding: 0.5rem 1rem;
+  margin-bottom: 1rem;
+  border-bottom: 1px solid var(--ifm-color-emphasis-200);
+}
+
+.versionContainer {
+  display: flex;
+  align-items: center;
+  max-width: var(--ifm-container-width);
+  margin: 0 auto;
+  padding: 0 var(--ifm-spacing-horizontal);
+}
+
+.versionLabel {
+  font-weight: bold;
+  margin-right: 0.5rem;
+}
+
+.versionSelector {
+  cursor: pointer;
+  color: var(--ifm-color-primary);
+  font-weight: 500;
+}
+
+.versionSelector:hover {
+  text-decoration: none;
+  color: var(--ifm-color-primary-darker);
+}

docs/src/webpack.extend.ts

@@ -0,0 +1,115 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import path from 'path';
+import type { Plugin } from '@docusaurus/types';
+
+export default function webpackExtendPlugin(): Plugin<void> {
+  return {
+    name: 'custom-webpack-plugin',
+    configureWebpack(config, isServer, utils) {
+      const { isDev } = utils;
+      return {
+        devtool: isDev ? 'eval-source-map' : config.devtool,
+        ...(isDev && {
+          optimization: {
+            ...config.optimization,
+            minimize: false,
+            removeAvailableModules: false,
+            removeEmptyChunks: false,
+            splitChunks: false,
+          },
+        }),
+        resolve: {
+          alias: {
+            ...config.resolve.alias,
+            // Allow importing from superset-frontend
+            src: path.resolve(__dirname, '../../superset-frontend/src'),
+            // '@superset-ui/core': path.resolve(
+            //   __dirname,
+            //   '../../superset-frontend/packages/superset-ui-core',
+            // ),
+            // Add aliases for our components to make imports easier
+            '@docs/components': path.resolve(__dirname, '../src/components'),
+            '@superset/components': path.resolve(
+              __dirname,
+              '../../superset-frontend/packages/superset-ui-core/src/components',
+            ),
+            // Add proper Storybook aliases
+            '@storybook/blocks': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/blocks',
+            ),
+            '@storybook/components': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/components',
+            ),
+            '@storybook/theming': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/theming',
+            ),
+            '@storybook/client-logger': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/client-logger',
+            ),
+            '@storybook/core-events': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/core-events',
+            ),
+            // Add internal Storybook aliases
+            'storybook/internal/components': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/components',
+            ),
+            'storybook/internal/theming': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/theming',
+            ),
+            'storybook/internal/client-logger': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/client-logger',
+            ),
+            'storybook/internal/csf': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/csf',
+            ),
+            'storybook/internal/preview-api': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/preview-api',
+            ),
+            'storybook/internal/docs-tools': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/docs-tools',
+            ),
+            'storybook/internal/core-events': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/core-events',
+            ),
+            'storybook/internal/channels': path.resolve(
+              __dirname,
+              '../node_modules/@storybook/channels',
+            ),
+          },
+        },
+        // We're removing the ts-loader rule that was processing superset-frontend files
+        // This will prevent TypeScript errors from files outside the docs directory
+      };
+    },
+  };
+}

docs/tutorials_versions.json

@@ -0,0 +1,3 @@
+[
+  "1.0.0"
+]

docs/versioned_docs/version-6.0.0/api.mdx

@@ -0,0 +1,35 @@
+---
+title: API
+hide_title: true
+sidebar_position: 10
+---
+
+import SwaggerUI from 'swagger-ui-react';
+import openapi from '/resources/openapi.json';
+import 'swagger-ui-react/swagger-ui.css';
+import { Alert } from 'antd';
+
+## API
+
+Superset's public **REST API** follows the
+[OpenAPI specification](https://swagger.io/specification/), and is
+documented here. The docs below are generated using
+[Swagger React UI](https://www.npmjs.com/package/swagger-ui-react).
+
+<Alert
+  type="info"
+  message={
+    <div>
+      <strong>NOTE! </strong>
+      You can find an interactive version of this documentation on your local Superset
+      instance at <strong>/swagger/v1</strong> (unless disabled)
+    </div>
+  }
+/>
+
+<br />
+<br />
+<hr />
+<div className="swagger-container">
+  <SwaggerUI spec={openapi} />
+</div>

docs/versioned_docs/version-6.0.0/configuration/alerts-reports.mdx

@@ -0,0 +1,436 @@
+---
+title: Alerts and Reports
+hide_title: true
+sidebar_position: 2
+version: 2
+---
+
+# Alerts and Reports
+
+Users can configure automated alerts and reports to send dashboards or charts to an email recipient or Slack channel.
+
+- *Alerts* are sent when a SQL condition is reached
+- *Reports* are sent on a schedule
+
+Alerts and reports are disabled by default. To turn them on, you need to do some setup, described here.
+
+## Requirements
+
+### Commons
+
+#### In your `superset_config.py` or `superset_config_docker.py`
+
+- `"ALERT_REPORTS"` [feature flag](/docs/configuration/configuring-superset#feature-flags) must be turned to True.
+- `beat_schedule` in CeleryConfig must contain schedule for `reports.scheduler`.
+- At least one of those must be configured, depending on what you want to use:
+  - emails: `SMTP_*` settings
+  - Slack messages: `SLACK_API_TOKEN`
+- Users can customize the email subject by including date code placeholders, which will automatically be replaced with the corresponding UTC date when the email is sent. To enable this functionality, activate the `"DATE_FORMAT_IN_EMAIL_SUBJECT"` [feature flag](/docs/configuration/configuring-superset#feature-flags). This enables date formatting in email subjects, preventing all reporting emails from being grouped into the same thread (optional for the reporting feature).
+    - Use date codes from [strftime.org](https://strftime.org/) to create the email subject.
+    - If no date code is provided, the original string will be used as the email subject.
+
+##### Disable dry-run mode
+
+Screenshots will be taken but no messages actually sent as long as `ALERT_REPORTS_NOTIFICATION_DRY_RUN = True`, its default value in `docker/pythonpath_dev/superset_config.py`.  To disable dry-run mode and start receiving email/Slack notifications, set `ALERT_REPORTS_NOTIFICATION_DRY_RUN` to `False` in [superset config](https://github.com/apache/superset/blob/master/docker/pythonpath_dev/superset_config.py).
+
+#### In your `Dockerfile`
+
+- You must install a headless browser, for taking screenshots of the charts and dashboards. Only Firefox and Chrome are currently supported.
+  > If you choose Chrome, you must also change the value of `WEBDRIVER_TYPE` to `"chrome"` in your `superset_config.py`.
+
+Note: All the components required (Firefox headless browser, Redis, Postgres db, celery worker and celery beat) are present in the *dev* docker image if you are following [Installing Superset Locally](/docs/installation/docker-compose/).
+All you need to do is add the required config variables described in this guide (See `Detailed Config`).
+
+If you are running a non-dev docker image, e.g., a stable release like `apache/superset:3.1.0`, that image does not include a headless browser.  Only the `superset_worker` container needs this headless browser to browse to the target chart or dashboard.
+You can either install and configure the headless browser - see "Custom Dockerfile" section below - or when deploying via `docker compose`, modify your `docker-compose.yml` file to use a dev image for the worker container and a stable release image for the `superset_app` container.
+
+*Note*: In this context, a "dev image" is the same application software as its corresponding non-dev image, just bundled with additional tools.  So an image like `3.1.0-dev` is identical to `3.1.0` when it comes to stability, functionality, and running in production.  The actual "in-development" versions of Superset - cutting-edge and unstable - are not tagged with version numbers on Docker Hub and will display version `0.0.0-dev` within the Superset UI.
+
+### Slack integration
+
+To send alerts and reports to Slack channels, you need to create a new Slack Application on your workspace.
+
+1. Connect to your Slack workspace, then head to [https://api.slack.com/apps].
+2. Create a new app.
+3. Go to "OAuth & Permissions" section, and give the following scopes to your app:
+   - `incoming-webhook`
+   - `files:write`
+   - `chat:write`
+   - `channels:read`
+   - `groups:read`
+4. At the top of the "OAuth and Permissions" section, click "install to workspace".
+5. Select a default channel for your app and continue.
+   (You can post to any channel by inviting your Superset app into that channel).
+6. The app should now be installed in your workspace, and a "Bot User OAuth Access Token" should have been created. Copy that token in the `SLACK_API_TOKEN` variable of your `superset_config.py`.
+7. Ensure the feature flag `ALERT_REPORT_SLACK_V2` is set to True in `superset_config.py`
+8. Restart the service (or run `superset init`) to pull in the new configuration.
+
+Note: when you configure an alert or a report, the Slack channel list takes channel names without the leading '#' e.g. use `alerts` instead of `#alerts`.
+
+### Kubernetes-specific
+
+- You must have a `celery beat` pod running. If you're using the chart included in the GitHub repository under [helm/superset](https://github.com/apache/superset/tree/master/helm/superset), you need to put `supersetCeleryBeat.enabled = true` in your values override.
+- You can see the dedicated docs about [Kubernetes installation](/docs/installation/kubernetes) for more details.
+
+### Docker Compose specific
+
+#### You must have in your `docker-compose.yml`
+
+- A Redis message broker
+- PostgreSQL DB instead of SQLlite
+- One or more `celery worker`
+- A single `celery beat`
+
+This process also works in a Docker swarm environment, you would just need to add `Deploy:` to the Superset, Redis and Postgres services along with your specific configs for your swarm.
+
+### Detailed config
+
+The following configurations need to be added to the `superset_config.py` file. This file is loaded when the image runs, and any configurations in it will override the default configurations found in the `config.py`.
+
+You can find documentation about each field in the default `config.py` in the GitHub repository under [superset/config.py](https://github.com/apache/superset/blob/master/superset/config.py).
+
+You need to replace default values with your custom Redis, Slack and/or SMTP config.
+
+Superset uses Celery beat and Celery worker(s) to send alerts and reports.
+
+- The beat is the scheduler that tells the worker when to perform its tasks. This schedule is defined when you create the alert or report.
+- The worker will process the  tasks that need to be performed when an alert or report is fired.
+
+In the `CeleryConfig`, only the `beat_schedule` is relevant to this feature, the rest of the `CeleryConfig` can be changed for your needs.
+
+```python
+from celery.schedules import crontab
+
+FEATURE_FLAGS = {
+    "ALERT_REPORTS": True
+}
+
+REDIS_HOST = "superset_cache"
+REDIS_PORT = "6379"
+
+class CeleryConfig:
+    broker_url = f"redis://{REDIS_HOST}:{REDIS_PORT}/0"
+    imports = (
+        "superset.sql_lab",
+        "superset.tasks.scheduler",
+    )
+    result_backend = f"redis://{REDIS_HOST}:{REDIS_PORT}/0"
+    worker_prefetch_multiplier = 10
+    task_acks_late = True
+    task_annotations = {
+        "sql_lab.get_sql_results": {
+            "rate_limit": "100/s",
+        },
+    }
+    beat_schedule = {
+        "reports.scheduler": {
+            "task": "reports.scheduler",
+            "schedule": crontab(minute="*", hour="*"),
+        },
+        "reports.prune_log": {
+            "task": "reports.prune_log",
+            "schedule": crontab(minute=0, hour=0),
+        },
+    }
+CELERY_CONFIG = CeleryConfig
+
+SCREENSHOT_LOCATE_WAIT = 100
+SCREENSHOT_LOAD_WAIT = 600
+
+# Slack configuration
+SLACK_API_TOKEN = "xoxb-"
+
+# Email configuration
+SMTP_HOST = "smtp.sendgrid.net" # change to your host
+SMTP_PORT = 2525 # your port, e.g. 587
+SMTP_STARTTLS = True
+SMTP_SSL_SERVER_AUTH = True # If you're using an SMTP server with a valid certificate
+SMTP_SSL = False
+SMTP_USER = "your_user" # use the empty string "" if using an unauthenticated SMTP server
+SMTP_PASSWORD = "your_password" # use the empty string "" if using an unauthenticated SMTP server
+SMTP_MAIL_FROM = "noreply@youremail.com"
+EMAIL_REPORTS_SUBJECT_PREFIX = "[Superset] " # optional - overwrites default value in config.py of "[Report] "
+
+# WebDriver configuration
+# If you use Firefox, you can stick with default values
+# If you use Chrome, then add the following WEBDRIVER_TYPE and WEBDRIVER_OPTION_ARGS
+WEBDRIVER_TYPE = "chrome"
+WEBDRIVER_OPTION_ARGS = [
+    "--force-device-scale-factor=2.0",
+    "--high-dpi-support=2.0",
+    "--headless",
+    "--disable-gpu",
+    "--disable-dev-shm-usage",
+    "--no-sandbox",
+    "--disable-setuid-sandbox",
+    "--disable-extensions",
+]
+
+# This is for internal use, you can keep http
+WEBDRIVER_BASEURL = "http://superset:8088" # When running using docker compose use "http://superset_app:8088'
+# This is the link sent to the recipient. Change to your domain, e.g. https://superset.mydomain.com
+WEBDRIVER_BASEURL_USER_FRIENDLY = "http://localhost:8088"
+```
+
+You also need
+to specify on behalf of which username to render the dashboards. In general, dashboards and charts
+are not accessible to unauthorized requests, that is why the worker needs to take over credentials
+of an existing user to take a snapshot.
+
+By default, Alerts and Reports are executed as the owner of the alert/report object. To use a fixed user account,
+just change the config as follows (`admin` in this example):
+
+```python
+from superset.tasks.types import FixedExecutor
+
+ALERT_REPORTS_EXECUTORS = [FixedExecutor("admin")]
+```
+
+Please refer to `ExecutorType` in the codebase for other executor types.
+
+**Important notes**
+
+- Be mindful of the concurrency setting for celery (using `-c 4`). Selenium/webdriver instances can
+  consume a lot of CPU / memory on your servers.
+- In some cases, if you notice a lot of leaked geckodriver processes, try running your celery
+  processes with `celery worker --pool=prefork --max-tasks-per-child=128 ...`
+- It is recommended to run separate workers for the `sql_lab` and `email_reports` tasks. This can be
+  done using the `queue` field in `task_annotations`.
+- Adjust `WEBDRIVER_BASEURL` in your configuration file if celery workers can’t access Superset via
+  its default value of `http://0.0.0.0:8080/`.
+
+It's also possible to specify a minimum interval between each report's execution through the config file:
+
+``` python
+# Set a minimum interval threshold between executions (for each Alert/Report)
+# Value should be an integer
+ALERT_MINIMUM_INTERVAL = int(timedelta(minutes=10).total_seconds())
+REPORT_MINIMUM_INTERVAL = int(timedelta(minutes=5).total_seconds())
+```
+
+Alternatively, you can assign a function to `ALERT_MINIMUM_INTERVAL` and/or `REPORT_MINIMUM_INTERVAL`. This is useful to dynamically retrieve a value as needed:
+
+``` python
+def alert_dynamic_minimal_interval(**kwargs) -> int:
+    """
+    Define logic here to retrieve the value dynamically
+    """
+
+ALERT_MINIMUM_INTERVAL = alert_dynamic_minimal_interval
+```
+
+## Custom Dockerfile
+
+If you're running the dev version of a released Superset image, like `apache/superset:3.1.0-dev`, you should be set with the above.
+
+But if you're building your own image, or starting with a non-dev version, a webdriver (and headless browser) is needed to capture screenshots of the charts and dashboards which are then sent to the recipient.
+Here's how you can modify your Dockerfile to take the screenshots either with Firefox or Chrome.
+
+### Using Firefox
+
+```docker
+FROM apache/superset:3.1.0
+
+USER root
+
+RUN apt-get update && \
+    apt-get install --no-install-recommends -y firefox-esr
+
+ENV GECKODRIVER_VERSION=0.29.0
+RUN wget -q https://github.com/mozilla/geckodriver/releases/download/v${GECKODRIVER_VERSION}/geckodriver-v${GECKODRIVER_VERSION}-linux64.tar.gz && \
+    tar -x geckodriver -zf geckodriver-v${GECKODRIVER_VERSION}-linux64.tar.gz -O > /usr/bin/geckodriver && \
+    chmod 755 /usr/bin/geckodriver && \
+    rm geckodriver-v${GECKODRIVER_VERSION}-linux64.tar.gz
+
+RUN pip install --no-cache gevent psycopg2 redis
+
+USER superset
+```
+
+### Using Chrome
+
+```docker
+FROM apache/superset:3.1.0
+
+USER root
+
+RUN apt-get update && \
+    apt-get install -y wget zip libaio1
+
+RUN export CHROMEDRIVER_VERSION=$(curl --silent https://googlechromelabs.github.io/chrome-for-testing/LATEST_RELEASE_116) && \
+    wget -O google-chrome-stable_current_amd64.deb -q http://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_${CHROMEDRIVER_VERSION}-1_amd64.deb && \
+    apt-get install -y --no-install-recommends ./google-chrome-stable_current_amd64.deb && \
+    rm -f google-chrome-stable_current_amd64.deb
+
+RUN export CHROMEDRIVER_VERSION=$(curl --silent https://googlechromelabs.github.io/chrome-for-testing/LATEST_RELEASE_116) && \
+    wget -q https://storage.googleapis.com/chrome-for-testing-public/${CHROMEDRIVER_VERSION}/linux64/chromedriver-linux64.zip && \
+    unzip -j chromedriver-linux64.zip -d /usr/bin && \
+    chmod 755 /usr/bin/chromedriver && \
+    rm -f chromedriver-linux64.zip
+
+RUN pip install --no-cache gevent psycopg2 redis
+
+USER superset
+```
+
+Don't forget to set `WEBDRIVER_TYPE` and `WEBDRIVER_OPTION_ARGS` in your config if you use Chrome.
+
+## Troubleshooting
+
+There are many reasons that reports might not be working.  Try these steps to check for specific issues.
+
+### Confirm feature flag is enabled and you have sufficient permissions
+
+If you don't see "Alerts & Reports" under the *Manage* section of the Settings dropdown in the Superset UI, you need to enable the `ALERT_REPORTS` feature flag (see above). Enable another feature flag and check to see that it took effect, to verify that your config file is getting loaded.
+
+Log in as an admin user to ensure you have adequate permissions.
+
+### Check the logs of your Celery worker
+
+This is the best source of information about the problem.  In a docker compose deployment, you can do this with a command like `docker logs superset_worker --since 1h`.
+
+### Check web browser and webdriver installation
+
+To take a screenshot, the worker visits the dashboard or chart using a headless browser, then takes a screenshot. If you are able to send a chart as CSV or text but can't send as PNG, your problem may lie with the browser.
+
+Superset docker images that have a tag ending with `-dev` have the Firefox headless browser and geckodriver already installed. You can test that these are installed and in the proper path by entering your Superset worker and running `firefox --headless` and then `geckodriver`. Both commands should start those applications.
+
+If you are handling the installation of that software on your own, or wish to use Chromium instead, do your own verification to ensure that the headless browser opens successfully in the worker environment.
+
+### Send a test email
+
+One symptom of an invalid connection to an email server is receiving an error of `[Errno 110] Connection timed out` in your logs when the report tries to send.
+
+Confirm via testing that your outbound email configuration is correct.  Here is the simplest test, for an un-authenticated email SMTP email service running on port 25.  If you are sending over SSL, for instance, study how [Superset's codebase sends emails](https://github.com/apache/superset/blob/master/superset/utils/core.py#L818) and then test with those commands and arguments.
+
+Start Python in your worker environment, replace all example values, and run:
+
+```python
+import smtplib
+from email.mime.multipart import MIMEMultipart
+from email.mime.text import MIMEText
+
+from_email = 'superset_emails@example.com'
+to_email = 'your_email@example.com'
+msg = MIMEMultipart()
+msg['From'] = from_email
+msg['To'] = to_email
+msg['Subject'] = 'Superset SMTP config test'
+message = 'It worked'
+msg.attach(MIMEText(message))
+mailserver = smtplib.SMTP('smtpmail.example.com', 25)
+mailserver.sendmail(from_email, to_email, msg.as_string())
+mailserver.quit()
+```
+
+This should send an email.
+
+Possible fixes:
+
+- Some cloud hosts disable outgoing unauthenticated SMTP email to prevent spam.  For instance, [Azure blocks port 25 by default on some machines](https://learn.microsoft.com/en-us/azure/virtual-network/troubleshoot-outbound-smtp-connectivity). Enable that port or use another sending method.
+- Use another set of SMTP credentials that you verify works in this setup.
+
+### Browse to your report from the worker
+
+The worker may be unable to reach the report. It will use the value of `WEBDRIVER_BASEURL` to browse to the report.  If that route is invalid, or presents an authentication challenge that the worker can't pass, the report screenshot will fail.
+
+Check this by attempting to `curl` the URL of a report that you see in the error logs of your worker. For instance, from the worker environment, run `curl http://superset_app:8088/superset/dashboard/1/`. You may get different responses depending on whether the dashboard exists - for example, you may need to change the `1` in that URL. If there's a URL in your logs from a failed report screenshot, that's a good place to start. The goal is to determine a valid value for `WEBDRIVER_BASEURL` and determine if an issue like HTTPS or authentication is redirecting your worker.
+
+In a deployment with authentication measures enabled like HTTPS and Single Sign-On, it may make sense to have the worker navigate directly to the Superset application running in the same location, avoiding the need to sign in.  For instance, you could use `WEBDRIVER_BASEURL="http://superset_app:8088"` for a docker compose deployment, and set `"force_https": False,` in your `TALISMAN_CONFIG`.
+
+## Scheduling Queries as Reports
+
+You can optionally allow your users to schedule queries directly in SQL Lab. This is done by adding
+extra metadata to saved queries, which are then picked up by an external scheduled (like
+[Apache Airflow](https://airflow.apache.org/)).
+
+To allow scheduled queries, add the following to `SCHEDULED_QUERIES` in your configuration file:
+
+```python
+SCHEDULED_QUERIES = {
+    # This information is collected when the user clicks "Schedule query",
+    # and saved into the `extra` field of saved queries.
+    # See: https://github.com/mozilla-services/react-jsonschema-form
+    'JSONSCHEMA': {
+        'title': 'Schedule',
+        'description': (
+            'In order to schedule a query, you need to specify when it '
+            'should start running, when it should stop running, and how '
+            'often it should run. You can also optionally specify '
+            'dependencies that should be met before the query is '
+            'executed. Please read the documentation for best practices '
+            'and more information on how to specify dependencies.'
+        ),
+        'type': 'object',
+        'properties': {
+            'output_table': {
+                'type': 'string',
+                'title': 'Output table name',
+            },
+            'start_date': {
+                'type': 'string',
+                'title': 'Start date',
+                # date-time is parsed using the chrono library, see
+                # https://www.npmjs.com/package/chrono-node#usage
+                'format': 'date-time',
+                'default': 'tomorrow at 9am',
+            },
+            'end_date': {
+                'type': 'string',
+                'title': 'End date',
+                # date-time is parsed using the chrono library, see
+                # https://www.npmjs.com/package/chrono-node#usage
+                'format': 'date-time',
+                'default': '9am in 30 days',
+            },
+            'schedule_interval': {
+                'type': 'string',
+                'title': 'Schedule interval',
+            },
+            'dependencies': {
+                'type': 'array',
+                'title': 'Dependencies',
+                'items': {
+                    'type': 'string',
+                },
+            },
+        },
+    },
+    'UISCHEMA': {
+        'schedule_interval': {
+            'ui:placeholder': '@daily, @weekly, etc.',
+        },
+        'dependencies': {
+            'ui:help': (
+                'Check the documentation for the correct format when '
+                'defining dependencies.'
+            ),
+        },
+    },
+    'VALIDATION': [
+        # ensure that start_date <= end_date
+        {
+            'name': 'less_equal',
+            'arguments': ['start_date', 'end_date'],
+            'message': 'End date cannot be before start date',
+            # this is where the error message is shown
+            'container': 'end_date',
+        },
+    ],
+    # link to the scheduler; this example links to an Airflow pipeline
+    # that uses the query id and the output table as its name
+    'linkback': (
+        'https://airflow.example.com/admin/airflow/tree?'
+        'dag_id=query_${id}_${extra_json.schedule_info.output_table}'
+    ),
+}
+```
+
+This configuration is based on
+[react-jsonschema-form](https://github.com/mozilla-services/react-jsonschema-form) and will add a
+menu item called “Schedule” to SQL Lab. When the menu item is clicked, a modal will show up where
+the user can add the metadata required for scheduling the query.
+
+This information can then be retrieved from the endpoint `/api/v1/saved_query/` and used to
+schedule the queries that have `schedule_info` in their JSON metadata. For schedulers other than
+Airflow, additional fields can be easily added to the configuration file above.

docs/versioned_docs/version-6.0.0/configuration/async-queries-celery.mdx

@@ -0,0 +1,104 @@
+---
+title: Async Queries via Celery
+hide_title: true
+sidebar_position: 4
+version: 1
+---
+
+# Async Queries via Celery
+
+## Celery
+
+On large analytic databases, it’s common to run queries that execute for minutes or hours. To enable
+support for long running queries that execute beyond the typical web request’s timeout (30-60
+seconds), it is necessary to configure an asynchronous backend for Superset which consists of:
+
+- one or many Superset workers (which is implemented as a Celery worker), and can be started with
+  the `celery worker` command, run `celery worker --help` to view the related options.
+- a celery broker (message queue) for which we recommend using Redis or RabbitMQ
+- a results backend that defines where the worker will persist the query results
+
+Configuring Celery requires defining a `CELERY_CONFIG` in your `superset_config.py`. Both the worker
+and web server processes should have the same configuration.
+
+```python
+class CeleryConfig(object):
+    broker_url = "redis://localhost:6379/0"
+    imports = (
+        "superset.sql_lab",
+        "superset.tasks.scheduler",
+    )
+    result_backend = "redis://localhost:6379/0"
+    worker_prefetch_multiplier = 10
+    task_acks_late = True
+    task_annotations = {
+        "sql_lab.get_sql_results": {
+            "rate_limit": "100/s",
+        },
+    }
+
+CELERY_CONFIG = CeleryConfig
+```
+
+To start a Celery worker to leverage the configuration, run the following command:
+
+```bash
+celery --app=superset.tasks.celery_app:app worker --pool=prefork -O fair -c 4
+```
+
+To start a job which schedules periodic background jobs, run the following command:
+
+```bash
+celery --app=superset.tasks.celery_app:app beat
+```
+
+To setup a result backend, you need to pass an instance of a derivative of from
+from flask_caching.backends.base import BaseCache to the RESULTS_BACKEND configuration key in your superset_config.py. You can
+use Memcached, Redis, S3 (https://pypi.python.org/pypi/s3werkzeugcache), memory or the file system
+(in a single server-type setup or for testing), or to write your own caching interface. Your
+`superset_config.py` may look something like:
+
+```python
+# On S3
+from s3cache.s3cache import S3Cache
+S3_CACHE_BUCKET = 'foobar-superset'
+S3_CACHE_KEY_PREFIX = 'sql_lab_result'
+RESULTS_BACKEND = S3Cache(S3_CACHE_BUCKET, S3_CACHE_KEY_PREFIX)
+
+# On Redis
+from flask_caching.backends.rediscache import RedisCache
+RESULTS_BACKEND = RedisCache(
+    host='localhost', port=6379, key_prefix='superset_results')
+```
+
+For performance gains, [MessagePack](https://github.com/msgpack/msgpack-python) and
+[PyArrow](https://arrow.apache.org/docs/python/) are now used for results serialization. This can be
+disabled by setting `RESULTS_BACKEND_USE_MSGPACK = False` in your `superset_config.py`, should any
+issues arise. Please clear your existing results cache store when upgrading an existing environment.
+
+**Important Notes**
+
+- It is important that all the worker nodes and web servers in the Superset cluster _share a common
+  metadata database_. This means that SQLite will not work in this context since it has limited
+  support for concurrency and typically lives on the local file system.
+
+- There should _only be one instance of celery beat running_ in your entire setup. If not,
+  background jobs can get scheduled multiple times resulting in weird behaviors like duplicate
+  delivery of reports, higher than expected load / traffic etc.
+
+- SQL Lab will _only run your queries asynchronously if_ you enable **Asynchronous Query Execution**
+  in your database settings (Sources > Databases > Edit record).
+
+## Celery Flower
+
+Flower is a web based tool for monitoring the Celery cluster which you can install from pip:
+
+```bash
+pip install flower
+```
+
+You can run flower using:
+
+```bash
+celery --app=superset.tasks.celery_app:app flower
+```

docs/versioned_docs/version-6.0.0/configuration/cache.mdx

@@ -0,0 +1,154 @@
+---
+title: Caching
+hide_title: true
+sidebar_position: 3
+version: 1
+---
+
+# Caching
+
+Superset uses [Flask-Caching](https://flask-caching.readthedocs.io/) for caching purposes.
+Flask-Caching supports various caching backends, including Redis (recommended), Memcached,
+SimpleCache (in-memory), or the local filesystem.
+[Custom cache backends](https://flask-caching.readthedocs.io/en/latest/#custom-cache-backends)
+are also supported.
+
+Caching can be configured by providing dictionaries in
+`superset_config.py` that comply with [the Flask-Caching config specifications](https://flask-caching.readthedocs.io/en/latest/#configuring-flask-caching).
+
+The following cache configurations can be customized in this way:
+
+- Dashboard filter state (required): `FILTER_STATE_CACHE_CONFIG`.
+- Explore chart form data (required): `EXPLORE_FORM_DATA_CACHE_CONFIG`
+- Metadata cache (optional): `CACHE_CONFIG`
+- Charting data queried from datasets (optional): `DATA_CACHE_CONFIG`
+
+For example, to configure the filter state cache using Redis:
+
+```python
+FILTER_STATE_CACHE_CONFIG = {
+    'CACHE_TYPE': 'RedisCache',
+    'CACHE_DEFAULT_TIMEOUT': 86400,
+    'CACHE_KEY_PREFIX': 'superset_filter_cache',
+    'CACHE_REDIS_URL': 'redis://localhost:6379/0'
+}
+```
+
+## Dependencies
+
+In order to use dedicated cache stores, additional python libraries must be installed
+
+- For Redis: we recommend the [redis](https://pypi.python.org/pypi/redis) Python package
+- Memcached: we recommend using [pylibmc](https://pypi.org/project/pylibmc/) client library as
+  `python-memcached` does not handle storing binary data correctly.
+
+These libraries can be installed using pip.
+
+## Fallback Metastore Cache
+
+Note, that some form of Filter State and Explore caching are required. If either of these caches
+are undefined, Superset falls back to using a built-in cache that stores data in the metadata
+database. While it is recommended to use a dedicated cache, the built-in cache can also be used
+to cache other data.
+
+For example, to use the built-in cache to store chart data, use the following config:
+
+```python
+DATA_CACHE_CONFIG = {
+    "CACHE_TYPE": "SupersetMetastoreCache",
+    "CACHE_KEY_PREFIX": "superset_results",  # make sure this string is unique to avoid collisions
+    "CACHE_DEFAULT_TIMEOUT": 86400,  # 60 seconds * 60 minutes * 24 hours
+}
+```
+
+## Chart Cache Timeout
+
+The cache timeout for charts may be overridden by the settings for an individual chart, dataset, or
+database. Each of these configurations will be checked in order before falling back to the default
+value defined in `DATA_CACHE_CONFIG`.
+
+Note, that by setting the cache timeout to `-1`, caching for charting data can be disabled, either
+per chart, dataset or database, or by default if set in `DATA_CACHE_CONFIG`.
+
+## SQL Lab Query Results
+
+Caching for SQL Lab query results is used when async queries are enabled and is configured using
+`RESULTS_BACKEND`.
+
+Note that this configuration does not use a flask-caching dictionary for its configuration, but
+instead requires a cachelib object.
+
+See [Async Queries via Celery](/docs/configuration/async-queries-celery) for details.
+
+## Caching Thumbnails
+
+This is an optional feature that can be turned on by activating its [feature flag](/docs/configuration/configuring-superset#feature-flags) on config:
+
+```
+FEATURE_FLAGS = {
+    "THUMBNAILS": True,
+    "THUMBNAILS_SQLA_LISTENERS": True,
+}
+```
+
+By default thumbnails are rendered per user, and will fall back to the Selenium user for anonymous users.
+To always render thumbnails as a fixed user (`admin` in this example), use the following configuration:
+
+```python
+from superset.tasks.types import FixedExecutor
+
+THUMBNAIL_EXECUTORS = [FixedExecutor("admin")]
+```
+
+For this feature you will need a cache system and celery workers. All thumbnails are stored on cache
+and are processed asynchronously by the workers.
+
+An example config where images are stored on S3 could be:
+
+```python
+from flask import Flask
+from s3cache.s3cache import S3Cache
+
+...
+
+class CeleryConfig(object):
+    broker_url = "redis://localhost:6379/0"
+    imports = (
+        "superset.sql_lab",
+        "superset.tasks.thumbnails",
+    )
+    result_backend = "redis://localhost:6379/0"
+    worker_prefetch_multiplier = 10
+    task_acks_late = True
+
+
+CELERY_CONFIG = CeleryConfig
+
+def init_thumbnail_cache(app: Flask) -> S3Cache:
+    return S3Cache("bucket_name", 'thumbs_cache/')
+
+
+THUMBNAIL_CACHE_CONFIG = init_thumbnail_cache
+```
+
+Using the above example cache keys for dashboards will be `superset_thumb__dashboard__{ID}`. You can
+override the base URL for selenium using:
+
+```
+WEBDRIVER_BASEURL = "https://superset.company.com"
+```
+
+Additional selenium web drive configuration can be set using `WEBDRIVER_CONFIGURATION`. You can
+implement a custom function to authenticate selenium. The default function uses the `flask-login`
+session cookie. Here's an example of a custom function signature:
+
+```python
+def auth_driver(driver: WebDriver, user: "User") -> WebDriver:
+    pass
+```
+
+Then on configuration:
+
+```
+WEBDRIVER_AUTH_FUNC = auth_driver
+```

docs/versioned_docs/version-6.0.0/configuration/configuring-superset.mdx

@@ -0,0 +1,548 @@
+---
+title: Configuring Superset
+hide_title: true
+sidebar_position: 1
+version: 1
+---
+
+# Configuring Superset
+
+## superset_config.py
+
+Superset exposes hundreds of configurable parameters through its
+[config.py module](https://github.com/apache/superset/blob/master/superset/config.py). The
+variables and objects exposed act as a public interface of the bulk of what you may want
+to configure, alter and interface with. In this python module, you'll find all these
+parameters, sensible defaults, as well as rich documentation in the form of comments
+
+To configure your application, you need to create your own configuration module, which
+will allow you to override few or many of these parameters. Instead of altering the core module,
+you'll want to define your own module (typically a file named `superset_config.py`).
+Add this file to your `PYTHONPATH` or create an environment variable
+`SUPERSET_CONFIG_PATH` specifying the full path of the `superset_config.py`.
+
+For example, if deploying on Superset directly on a Linux-based system where your
+`superset_config.py` is under `/app` directory, you can run:
+
+```bash
+export SUPERSET_CONFIG_PATH=/app/superset_config.py
+```
+
+If you are using your own custom Dockerfile with the official Superset image as base image,
+then you can add your overrides as shown below:
+
+```bash
+COPY --chown=superset superset_config.py /app/
+ENV SUPERSET_CONFIG_PATH /app/superset_config.py
+```
+
+Docker compose deployments handle application configuration differently using specific conventions.
+Refer to the [docker compose tips & configuration](/docs/installation/docker-compose#docker-compose-tips--configuration)
+for details.
+
+The following is an example of just a few of the parameters you can set in your `superset_config.py` file:
+
+```
+# Superset specific config
+ROW_LIMIT = 5000
+
+# Flask App Builder configuration
+# Your App secret key will be used for securely signing the session cookie
+# and encrypting sensitive information on the database
+# Make sure you are changing this key for your deployment with a strong key.
+# Alternatively you can set it with `SUPERSET_SECRET_KEY` environment variable.
+# You MUST set this for production environments or the server will refuse
+# to start and you will see an error in the logs accordingly.
+SECRET_KEY = 'YOUR_OWN_RANDOM_GENERATED_SECRET_KEY'
+
+# The SQLAlchemy connection string to your database backend
+# This connection defines the path to the database that stores your
+# superset metadata (slices, connections, tables, dashboards, ...).
+# Note that the connection information to connect to the datasources
+# you want to explore are managed directly in the web UI
+# The check_same_thread=false property ensures the sqlite client does not attempt
+# to enforce single-threaded access, which may be problematic in some edge cases
+SQLALCHEMY_DATABASE_URI = 'sqlite:////path/to/superset.db?check_same_thread=false'
+
+# Flask-WTF flag for CSRF
+WTF_CSRF_ENABLED = True
+# Add endpoints that need to be exempt from CSRF protection
+WTF_CSRF_EXEMPT_LIST = []
+# A CSRF token that expires in 1 year
+WTF_CSRF_TIME_LIMIT = 60 * 60 * 24 * 365
+
+# Set this API key to enable Mapbox visualizations
+MAPBOX_API_KEY = ''
+```
+
+:::tip
+Note that it is typical to copy and paste [only] the portions of the
+core [superset/config.py](https://github.com/apache/superset/blob/master/superset/config.py) that
+you want to alter, along with the related comments into your own `superset_config.py` file.
+:::
+
+All the parameters and default values defined
+in [superset/config.py](https://github.com/apache/superset/blob/master/superset/config.py)
+can be altered in your local `superset_config.py`. Administrators will want to read through the file
+to understand what can be configured locally as well as the default values in place.
+
+Since `superset_config.py` acts as a Flask configuration module, it can be used to alter the
+settings of Flask itself, as well as Flask extensions that Superset bundles like
+`flask-wtf`, `flask-caching`, `flask-migrate`,
+and `flask-appbuilder`. Each one of these extensions offers intricate configurability.
+Flask App Builder, the web framework used by Superset, also offers many
+configuration settings. Please consult the
+[Flask App Builder Documentation](https://flask-appbuilder.readthedocs.org/en/latest/config.html)
+for more information on how to configure it.
+
+At the very least, you'll want to change `SECRET_KEY` and `SQLALCHEMY_DATABASE_URI`. Continue reading for more about each of these.
+
+## Specifying a SECRET_KEY
+
+### Adding an initial SECRET_KEY
+
+Superset requires a user-specified SECRET_KEY to start up. This requirement was [added in version 2.1.0 to force secure configurations](https://preset.io/blog/superset-security-update-default-secret_key-vulnerability/). Add a strong SECRET_KEY to your `superset_config.py` file like:
+
+```python
+SECRET_KEY = 'YOUR_OWN_RANDOM_GENERATED_SECRET_KEY'
+```
+
+You can generate a strong secure key with `openssl rand -base64 42`.
+
+:::caution Use a strong secret key
+This key will be used for securely signing session cookies and encrypting sensitive information stored in Superset's application metadata database.
+Your deployment must use a complex, unique key.
+:::
+
+### Rotating to a newer SECRET_KEY
+
+If you wish to change your existing SECRET_KEY, add the existing SECRET_KEY to your `superset_config.py` file as
+`PREVIOUS_SECRET_KEY =`and provide your new key as `SECRET_KEY =`. You can find your current SECRET_KEY with these
+commands - if running Superset with Docker, execute from within the Superset application container:
+
+```python
+superset shell
+from flask import current_app; print(current_app.config["SECRET_KEY"])
+```
+
+Save your `superset_config.py` with these values and then run `superset re-encrypt-secrets`.
+
+## Setting up a production metadata database
+
+Superset needs a database to store the information it manages, like the definitions of
+charts, dashboards, and many other things.
+
+By default, Superset is configured to use [SQLite](https://www.sqlite.org/),
+a self-contained, single-file database that offers a simple and fast way to get started
+(without requiring any installation). However, for production environments,
+using SQLite is highly discouraged due to security, scalability, and data integrity reasons.
+It's important to use only the supported database engines and consider using a different
+database engine on a separate host or container.
+
+Superset supports the following database engines/versions:
+
+| Database Engine                           | Supported Versions                       |
+| ----------------------------------------- | ---------------------------------------- |
+| [PostgreSQL](https://www.postgresql.org/) | 10.X, 11.X, 12.X, 13.X, 14.X, 15.X, 16.X |
+| [MySQL](https://www.mysql.com/)           | 5.7, 8.X                                 |
+
+Use the following database drivers and connection strings:
+
+| Database                                  | PyPI package              | Connection String                                                      |
+| ----------------------------------------- | ------------------------- | ---------------------------------------------------------------------- |
+| [PostgreSQL](https://www.postgresql.org/) | `pip install psycopg2`    | `postgresql://<UserName>:<DBPassword>@<Database Host>/<Database Name>` |
+| [MySQL](https://www.mysql.com/)           | `pip install mysqlclient` | `mysql://<UserName>:<DBPassword>@<Database Host>/<Database Name>`      |
+
+:::tip
+Properly setting up metadata store is beyond the scope of this documentation. We recommend
+using a hosted managed service such as [Amazon RDS](https://aws.amazon.com/rds/) or
+[Google Cloud Databases](https://cloud.google.com/products/databases?hl=en) to handle
+service and supporting infrastructure and backup strategy.
+:::
+
+To configure Superset metastore set `SQLALCHEMY_DATABASE_URI` config key on `superset_config`
+to the appropriate connection string.
+
+## Running on a WSGI HTTP Server
+
+While you can run Superset on NGINX or Apache, we recommend using Gunicorn in async mode. This
+enables impressive concurrency even and is fairly easy to install and configure. Please refer to the
+documentation of your preferred technology to set up this Flask WSGI application in a way that works
+well in your environment. Here’s an async setup known to work well in production:
+
+```
+      -w 10 \
+      -k gevent \
+      --worker-connections 1000 \
+      --timeout 120 \
+      -b  0.0.0.0:6666 \
+      --limit-request-line 0 \
+      --limit-request-field_size 0 \
+      --statsd-host localhost:8125 \
+      "superset.app:create_app()"
+```
+
+Refer to the [Gunicorn documentation](https://docs.gunicorn.org/en/stable/design.html) for more
+information. _Note that the development web server (`superset run` or `flask run`) is not intended
+for production use._
+
+If you're not using Gunicorn, you may want to disable the use of `flask-compress` by setting
+`COMPRESS_REGISTER = False` in your `superset_config.py`.
+
+Currently, the Google BigQuery Python SDK is not compatible with `gevent`, due to some dynamic monkeypatching on python core library by `gevent`.
+So, when you use `BigQuery` datasource on Superset, you have to use `gunicorn` worker type except `gevent`.
+
+## HTTPS Configuration
+
+You can configure HTTPS upstream via a load balancer or a reverse proxy (such as nginx) and do SSL/TLS Offloading before traffic reaches the Superset application. In this setup, local traffic from a Celery worker taking a snapshot of a chart for Alerts & Reports can access Superset at a `http://` URL, from behind the ingress point.
+You can also configure [SSL in Gunicorn](https://docs.gunicorn.org/en/stable/settings.html#ssl) (the Python webserver) if you are using an official Superset Docker image.
+
+## Configuration Behind a Load Balancer
+
+If you are running superset behind a load balancer or reverse proxy (e.g. NGINX or ELB on AWS), you
+may need to utilize a healthcheck endpoint so that your load balancer knows if your superset
+instance is running. This is provided at `/health` which will return a 200 response containing “OK”
+if the webserver is running.
+
+If the load balancer is inserting `X-Forwarded-For/X-Forwarded-Proto` headers, you should set
+`ENABLE_PROXY_FIX = True` in the superset config file (`superset_config.py`) to extract and use the
+headers.
+
+In case the reverse proxy is used for providing SSL encryption, an explicit definition of the
+`X-Forwarded-Proto` may be required. For the Apache webserver this can be set as follows:
+
+```
+RequestHeader set X-Forwarded-Proto "https"
+```
+
+## Configuring the application root
+
+*Please be advised that this feature is in BETA.*
+
+Superset supports running the application under a non-root path. The root path
+prefix can be specified in one of two ways:
+
+- Setting the `SUPERSET_APP_ROOT` environment variable to the desired prefix.
+- Customizing the [Flask entrypoint](https://github.com/apache/superset/blob/master/superset/app.py#L29)
+  by passing the `superset_app_root` variable.
+
+Note, the prefix should start with a `/`.
+
+### Customizing the Flask entrypoint
+
+To configure a prefix, e.g `/analytics`, pass the `superset_app_root` argument to
+`create_app` when calling flask run either through the `FLASK_APP`
+environment variable:
+
+```sh
+FLASK_APP="superset:create_app(superset_app_root='/analytics')"
+```
+
+or as part of the `--app` argument to `flask run`:
+
+```sh
+flask --app "superset.app:create_app(superset_app_root='/analytics')"
+```
+
+### Docker builds
+
+The [docker compose](/docs/installation/docker-compose#configuring-further) developer
+configuration includes an additional environmental variable,
+[`SUPERSET_APP_ROOT`](https://github.com/apache/superset/blob/master/docker/.env),
+to simplify the process of setting up a non-default root path across the services.
+
+In `docker/.env-local` set `SUPERSET_APP_ROOT` to the desired prefix and then bring the
+services up with `docker compose up --detach`.
+
+## Custom OAuth2 Configuration
+
+Superset is built on Flask-AppBuilder (FAB), which supports many providers out of the box
+(GitHub, Twitter, LinkedIn, Google, Azure, etc). Beyond those, Superset can be configured to connect
+with other OAuth2 Authorization Server implementations that support “code” authorization.
+
+Make sure the pip package [`Authlib`](https://authlib.org/) is installed on the webserver.
+
+First, configure authorization in Superset `superset_config.py`.
+
+```python
+from flask_appbuilder.security.manager import AUTH_OAUTH
+
+# Set the authentication type to OAuth
+AUTH_TYPE = AUTH_OAUTH
+
+OAUTH_PROVIDERS = [
+    {   'name':'egaSSO',
+        'token_key':'access_token', # Name of the token in the response of access_token_url
+        'icon':'fa-address-card',   # Icon for the provider
+        'remote_app': {
+            'client_id':'myClientId',  # Client Id (Identify Superset application)
+            'client_secret':'MySecret', # Secret for this Client Id (Identify Superset application)
+            'client_kwargs':{
+                'scope': 'read'               # Scope for the Authorization
+            },
+            'access_token_method':'POST',    # HTTP Method to call access_token_url
+            'access_token_params':{        # Additional parameters for calls to access_token_url
+                'client_id':'myClientId'
+            },
+            'jwks_uri':'https://myAuthorizationServe/adfs/discovery/keys', # may be required to generate token
+            'access_token_headers':{    # Additional headers for calls to access_token_url
+                'Authorization': 'Basic Base64EncodedClientIdAndSecret'
+            },
+            'api_base_url':'https://myAuthorizationServer/oauth2AuthorizationServer/',
+            'access_token_url':'https://myAuthorizationServer/oauth2AuthorizationServer/token',
+            'authorize_url':'https://myAuthorizationServer/oauth2AuthorizationServer/authorize'
+        }
+    }
+]
+
+# Will allow user self registration, allowing to create Flask users from Authorized User
+AUTH_USER_REGISTRATION = True
+
+# The default user self registration role
+AUTH_USER_REGISTRATION_ROLE = "Public"
+```
+
+In case you want to assign the `Admin` role on new user registration, it can be assigned as follows:
+```python
+AUTH_USER_REGISTRATION_ROLE = "Admin"
+```
+If you encounter the [issue](https://github.com/apache/superset/issues/13243) of not being able to list users from the Superset main page settings, although a newly registered user has an `Admin` role, please re-run `superset init` to sync the required permissions. Below is the command to re-run `superset init` using docker compose.
+```
+docker-compose exec superset superset init
+```
+
+Then, create a `CustomSsoSecurityManager` that extends `SupersetSecurityManager` and overrides
+`oauth_user_info`:
+
+```python
+import logging
+from superset.security import SupersetSecurityManager
+
+class CustomSsoSecurityManager(SupersetSecurityManager):
+
+    def oauth_user_info(self, provider, response=None):
+        logging.debug("Oauth2 provider: {0}.".format(provider))
+        if provider == 'egaSSO':
+            # As example, this line request a GET to base_url + '/' + userDetails with Bearer  Authentication,
+    # and expects that authorization server checks the token, and response with user details
+            me = self.appbuilder.sm.oauth_remotes[provider].get('userDetails').data
+            logging.debug("user_data: {0}".format(me))
+            return { 'name' : me['name'], 'email' : me['email'], 'id' : me['user_name'], 'username' : me['user_name'], 'first_name':'', 'last_name':''}
+    ...
+```
+
+This file must be located in the same directory as `superset_config.py` with the name
+`custom_sso_security_manager.py`. Finally, add the following 2 lines to `superset_config.py`:
+
+```
+from custom_sso_security_manager import CustomSsoSecurityManager
+CUSTOM_SECURITY_MANAGER = CustomSsoSecurityManager
+```
+
+**Notes**
+
+- The redirect URL will be `https://<superset-webserver>/oauth-authorized/<provider-name>`
+  When configuring an OAuth2 authorization provider if needed. For instance, the redirect URL will
+  be `https://<superset-webserver>/oauth-authorized/egaSSO` for the above configuration.
+
+- If an OAuth2 authorization server supports OpenID Connect 1.0, you could configure its configuration
+  document URL only without providing `api_base_url`, `access_token_url`, `authorize_url` and other
+  required options like user info endpoint, jwks uri etc. For instance:
+
+  ```python
+  OAUTH_PROVIDERS = [
+    {   'name':'egaSSO',
+        'token_key':'access_token', # Name of the token in the response of access_token_url
+        'icon':'fa-address-card',   # Icon for the provider
+        'remote_app': {
+            'client_id':'myClientId',  # Client Id (Identify Superset application)
+            'client_secret':'MySecret', # Secret for this Client Id (Identify Superset application)
+            'server_metadata_url': 'https://myAuthorizationServer/.well-known/openid-configuration'
+        }
+    }
+  ]
+  ```
+
+### Keycloak-Specific Configuration using Flask-OIDC
+
+If you are using Keycloak as OpenID Connect 1.0 Provider, the above configuration based on [`Authlib`](https://authlib.org/) might not work. In this case using [`Flask-OIDC`](https://pypi.org/project/flask-oidc/) is a viable option.
+
+Make sure the pip package [`Flask-OIDC`](https://pypi.org/project/flask-oidc/) is installed on the webserver. This was successfully tested using version 2.2.0. This package requires [`Flask-OpenID`](https://pypi.org/project/Flask-OpenID/) as a dependency.
+
+The following code defines a new security manager.  Add it to a new file named `keycloak_security_manager.py`, placed in the same directory as your `superset_config.py` file.
+
+```python
+from flask_appbuilder.security.manager import AUTH_OID
+from superset.security import SupersetSecurityManager
+from flask_oidc import OpenIDConnect
+from flask_appbuilder.security.views import AuthOIDView
+from flask_login import login_user
+from urllib.parse import quote
+from flask_appbuilder.views import ModelView, SimpleFormView, expose
+from flask import (
+    redirect,
+    request
+)
+import logging
+
+class OIDCSecurityManager(SupersetSecurityManager):
+
+    def __init__(self, appbuilder):
+        super(OIDCSecurityManager, self).__init__(appbuilder)
+        if self.auth_type == AUTH_OID:
+            self.oid = OpenIDConnect(self.appbuilder.get_app)
+        self.authoidview = AuthOIDCView
+
+class AuthOIDCView(AuthOIDView):
+
+    @expose('/login/', methods=['GET', 'POST'])
+    def login(self, flag=True):
+        sm = self.appbuilder.sm
+        oidc = sm.oid
+
+        @self.appbuilder.sm.oid.require_login
+        def handle_login():
+            user = sm.auth_user_oid(oidc.user_getfield('email'))
+
+            if user is None:
+                info = oidc.user_getinfo(['preferred_username', 'given_name', 'family_name', 'email'])
+                user = sm.add_user(info.get('preferred_username'), info.get('given_name'), info.get('family_name'),
+                                   info.get('email'), sm.find_role('Gamma'))
+
+            login_user(user, remember=False)
+            return redirect(self.appbuilder.get_url_for_index)
+
+        return handle_login()
+
+    @expose('/logout/', methods=['GET', 'POST'])
+    def logout(self):
+        oidc = self.appbuilder.sm.oid
+
+        oidc.logout()
+        super(AuthOIDCView, self).logout()
+        redirect_url = request.url_root.strip('/') + self.appbuilder.get_url_for_login
+
+        return redirect(
+            oidc.client_secrets.get('issuer') + '/protocol/openid-connect/logout?redirect_uri=' + quote(redirect_url))
+```
+
+Then add to your `superset_config.py` file:
+
+```python
+from keycloak_security_manager import OIDCSecurityManager
+from flask_appbuilder.security.manager import AUTH_OID, AUTH_REMOTE_USER, AUTH_DB, AUTH_LDAP, AUTH_OAUTH
+import os
+
+AUTH_TYPE = AUTH_OID
+SECRET_KEY: 'SomethingNotEntirelySecret'
+OIDC_CLIENT_SECRETS =  '/path/to/client_secret.json'
+OIDC_ID_TOKEN_COOKIE_SECURE = False
+OIDC_OPENID_REALM: '<myRealm>'
+OIDC_INTROSPECTION_AUTH_METHOD: 'client_secret_post'
+CUSTOM_SECURITY_MANAGER = OIDCSecurityManager
+
+# Will allow user self registration, allowing to create Flask users from Authorized User
+AUTH_USER_REGISTRATION = True
+
+# The default user self registration role
+AUTH_USER_REGISTRATION_ROLE = 'Public'
+```
+
+Store your client-specific OpenID information in a file called `client_secret.json`. Create this file in the same directory as `superset_config.py`:
+
+```json
+{
+    "<myOpenIDProvider>": {
+        "issuer": "https://<myKeycloakDomain>/realms/<myRealm>",
+        "auth_uri": "https://<myKeycloakDomain>/realms/<myRealm>/protocol/openid-connect/auth",
+        "client_id": "https://<myKeycloakDomain>",
+        "client_secret": "<myClientSecret>",
+        "redirect_uris": [
+            "https://<SupersetWebserver>/oauth-authorized/<myOpenIDProvider>"
+  ],
+        "userinfo_uri": "https://<myKeycloakDomain>/realms/<myRealm>/protocol/openid-connect/userinfo",
+        "token_uri": "https://<myKeycloakDomain>/realms/<myRealm>/protocol/openid-connect/token",
+        "token_introspection_uri": "https://<myKeycloakDomain>/realms/<myRealm>/protocol/openid-connect/token/introspect"
+  }
+}
+```
+
+## LDAP Authentication
+
+FAB supports authenticating user credentials against an LDAP server.
+To use LDAP you must install the [python-ldap](https://www.python-ldap.org/en/latest/installing.html) package.
+See [FAB's LDAP documentation](https://flask-appbuilder.readthedocs.io/en/latest/security.html#authentication-ldap)
+for details.
+
+## Mapping LDAP or OAUTH groups to Superset roles
+
+AUTH_ROLES_MAPPING in Flask-AppBuilder is a dictionary that maps from LDAP/OAUTH group names to FAB roles.
+It is used to assign roles to users who authenticate using LDAP or OAuth.
+
+### Mapping OAUTH groups to Superset roles
+
+The following `AUTH_ROLES_MAPPING` dictionary would map the OAUTH group "superset_users" to the Superset roles "Gamma" as well as "Alpha", and the OAUTH group "superset_admins" to the Superset role "Admin".
+
+```python
+AUTH_ROLES_MAPPING = {
+"superset_users": ["Gamma","Alpha"],
+"superset_admins": ["Admin"],
+}
+```
+
+### Mapping LDAP groups to Superset roles
+
+The following `AUTH_ROLES_MAPPING` dictionary would map the LDAP DN "cn=superset_users,ou=groups,dc=example,dc=com" to the Superset roles "Gamma" as well as "Alpha", and the LDAP DN "cn=superset_admins,ou=groups,dc=example,dc=com" to the Superset role "Admin".
+
+```python
+AUTH_ROLES_MAPPING = {
+"cn=superset_users,ou=groups,dc=example,dc=com": ["Gamma","Alpha"],
+"cn=superset_admins,ou=groups,dc=example,dc=com": ["Admin"],
+}
+```
+
+Note: This requires `AUTH_LDAP_SEARCH` to be set. For more details, please see the [FAB Security documentation](https://flask-appbuilder.readthedocs.io/en/latest/security.html).
+
+### Syncing roles at login
+
+You can also use the `AUTH_ROLES_SYNC_AT_LOGIN` configuration variable to control how often Flask-AppBuilder syncs the user's roles with the LDAP/OAUTH groups. If `AUTH_ROLES_SYNC_AT_LOGIN` is set to True, Flask-AppBuilder will sync the user's roles each time they log in. If `AUTH_ROLES_SYNC_AT_LOGIN` is set to False, Flask-AppBuilder will only sync the user's roles when they first register.
+
+## Flask app Configuration Hook
+
+`FLASK_APP_MUTATOR` is a configuration function that can be provided in your environment, receives
+the app object and can alter it in any way. For example, add `FLASK_APP_MUTATOR` into your
+`superset_config.py` to setup session cookie expiration time to 24 hours:
+
+```python
+from flask import session
+from flask import Flask
+
+
+def make_session_permanent():
+    '''
+    Enable maxAge for the cookie 'session'
+    '''
+    session.permanent = True
+
+# Set up max age of session to 24 hours
+PERMANENT_SESSION_LIFETIME = timedelta(hours=24)
+def FLASK_APP_MUTATOR(app: Flask) -> None:
+    app.before_request_funcs.setdefault(None, []).append(make_session_permanent)
+```
+
+## Feature Flags
+
+To support a diverse set of users, Superset has some features that are not enabled by default. For
+example, some users have stronger security restrictions, while some others may not. So Superset
+allows users to enable or disable some features by config. For feature owners, you can add optional
+functionalities in Superset, but will be only affected by a subset of users.
+
+You can enable or disable features with flag from `superset_config.py`:
+
+```python
+FEATURE_FLAGS = {
+    'PRESTO_EXPAND_DATA': False,
+}
+```
+
+A current list of feature flags can be found in [RESOURCES/FEATURE_FLAGS.md](https://github.com/apache/superset/blob/master/RESOURCES/FEATURE_FLAGS.md).

docs/versioned_docs/version-6.0.0/configuration/country-map-tools.mdx

@@ -0,0 +1,40 @@
+---
+title: Country Map Tools
+sidebar_position: 10
+version: 1
+---
+
+import countriesData from '../../../data/countries.json';
+
+# The Country Map Visualization
+
+The Country Map visualization allows you to plot lightweight choropleth maps of
+your countries by province, states, or other subdivision types. It does not rely
+on any third-party map services but would require you to provide the
+[ISO-3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) codes of your country's
+top-level subdivisions. Comparing to a province or state's full names, the ISO
+code is less ambiguous and is unique to all regions in the world.
+
+## Included Maps
+
+The current list of countries can be found in the src
+[legacy-plugin-chart-country-map/src/countries.ts](https://github.com/apache/superset/blob/master/superset-frontend/plugins/legacy-plugin-chart-country-map/src/countries.ts)
+
+The Country Maps visualization already ships with the maps for the following countries:
+
+<ul style={{columns: 3}}>
+{countriesData.countries.map((country, index) => (
+  <li key={index}>{country}</li>
+))}
+</ul>
+
+## Adding a New Country
+
+To add a new country to the list, you'd have to edit files in
+[@superset-ui/legacy-plugin-chart-country-map](https://github.com/apache/superset/tree/master/superset-frontend/plugins/legacy-plugin-chart-country-map).
+
+1. Generate a new GeoJSON file for your country following the guide in [this Jupyter notebook](https://github.com/apache/superset/blob/master/superset-frontend/plugins/legacy-plugin-chart-country-map/scripts/Country%20Map%20GeoJSON%20Generator.ipynb).
+2. Edit the countries list in [legacy-plugin-chart-country-map/src/countries.ts](https://github.com/apache/superset/blob/master/superset-frontend/plugins/legacy-plugin-chart-country-map/src/countries.ts).
+3. Install superset-frontend dependencies: `cd superset-frontend && npm install`
+4. Verify your countries in Superset plugins storybook: `npm run plugins:storybook`.
+5. Build and install Superset from source code.

docs/versioned_docs/version-6.0.0/configuration/event-logging.mdx

@@ -0,0 +1,62 @@
+---
+title: Event Logging
+sidebar_position: 9
+version: 1
+---
+
+# Logging
+
+## Event Logging
+
+Superset by default logs special action events in its internal database (DBEventLogger). These logs can be accessed
+on the UI by navigating to **Security > Action Log**. You can freely customize these logs by
+implementing your own event log class.
+**When custom log class is enabled DBEventLogger is disabled and logs
+stop being populated in UI logs view.**
+To achieve both, custom log class should extend built-in DBEventLogger log class.
+
+Here's an example of a simple JSON-to-stdout class:
+
+```python
+    def log(self, user_id, action, *args, **kwargs):
+        records = kwargs.get('records', list())
+        dashboard_id = kwargs.get('dashboard_id')
+        slice_id = kwargs.get('slice_id')
+        duration_ms = kwargs.get('duration_ms')
+        referrer = kwargs.get('referrer')
+
+        for record in records:
+            log = dict(
+                action=action,
+                json=record,
+                dashboard_id=dashboard_id,
+                slice_id=slice_id,
+                duration_ms=duration_ms,
+                referrer=referrer,
+                user_id=user_id
+            )
+            print(json.dumps(log))
+```
+
+End by updating your config to pass in an instance of the logger you want to use:
+
+```
+EVENT_LOGGER = JSONStdOutEventLogger()
+```
+
+## StatsD Logging
+
+Superset can be configured to log events to [StatsD](https://github.com/statsd/statsd)
+if desired. Most endpoints hit are logged as
+well as key events like query start and end in SQL Lab.
+
+To setup StatsD logging, it’s a matter of configuring the logger in your `superset_config.py`.
+If not already present, you need to ensure that the `statsd`-package is installed in Superset's python environment.
+
+```python
+from superset.stats_logger import StatsdStatsLogger
+STATS_LOGGER = StatsdStatsLogger(host='localhost', port=8125, prefix='superset')
+```
+
+Note that it’s also possible to implement your own logger by deriving
+`superset.stats_logger.BaseStatsLogger`.

docs/versioned_docs/version-6.0.0/configuration/importing-exporting-datasources.mdx

@@ -0,0 +1,126 @@
+---
+title: Importing and Exporting Datasources
+hide_title: true
+sidebar_position: 11
+version: 1
+---
+
+# Importing and Exporting Datasources
+
+The superset cli allows you to import and export datasources from and to YAML. Datasources include
+databases. The data is expected to be organized in the following hierarchy:
+
+```text
+├──databases
+|  ├──database_1
+|  |  ├──table_1
+|  |  |  ├──columns
+|  |  |  |  ├──column_1
+|  |  |  |  ├──column_2
+|  |  |  |  └──... (more columns)
+|  |  |  └──metrics
+|  |  |     ├──metric_1
+|  |  |     ├──metric_2
+|  |  |     └──... (more metrics)
+|  |  └── ... (more tables)
+|  └── ... (more databases)
+```
+
+## Exporting Datasources to YAML
+
+You can print your current datasources to stdout by running:
+
+```bash
+superset export_datasources
+```
+
+To save your datasources to a ZIP file run:
+
+```bash
+superset export_datasources -f <filename>
+```
+
+By default, default (null) values will be omitted. Use the -d flag to include them. If you want back
+references to be included (e.g. a column to include the table id it belongs to) use the -b flag.
+
+Alternatively, you can export datasources using the UI:
+
+1. Open **Sources -> Databases** to export all tables associated to a single or multiple databases.
+   (**Tables** for one or more tables)
+2. Select the items you would like to export.
+3. Click **Actions -> Export** to YAML
+4. If you want to import an item that you exported through the UI, you will need to nest it inside
+   its parent element, e.g. a database needs to be nested under databases a table needs to be nested
+   inside a database element.
+
+In order to obtain an **exhaustive list of all fields** you can import using the YAML import run:
+
+```bash
+superset export_datasource_schema
+```
+
+As a reminder, you can use the `-b` flag to include back references.
+
+## Importing Datasources
+
+In order to import datasources from a ZIP file, run:
+
+```bash
+superset import_datasources -p <path / filename>
+```
+
+The optional username flag **-u** sets the user used for the datasource import. The default is 'admin'. Example:
+
+```bash
+superset import_datasources -p <path / filename> -u 'admin'
+```
+
+## Legacy Importing Datasources
+
+### From older versions of Superset to current version
+
+When using Superset version 4.x.x to import from an older version (2.x.x or 3.x.x) importing is supported as the command `legacy_import_datasources` and expects a JSON or directory of JSONs. The options are `-r` for recursive and `-u` for specifying a user. Example of legacy import without options:
+
+```bash
+superset legacy_import_datasources -p <path or filename>
+```
+
+### From older versions of Superset to older versions
+
+When using an older Superset version (2.x.x & 3.x.x) of Superset, the command is `import_datasources`. ZIP and YAML files are supported and to switch between them the feature flag `VERSIONED_EXPORT` is used. When `VERSIONED_EXPORT` is `True`, `import_datasources` expects a ZIP file, otherwise YAML. Example:
+
+```bash
+superset import_datasources -p <path or filename>
+```
+
+When `VERSIONED_EXPORT` is `False`, if you supply a path all files ending with **yaml** or **yml** will be parsed. You can apply
+additional flags (e.g. to search the supplied path recursively):
+
+```bash
+superset import_datasources -p <path> -r
+```
+
+The sync flag **-s** takes parameters in order to sync the supplied elements with your file. Be
+careful this can delete the contents of your meta database. Example:
+
+```bash
+superset import_datasources -p <path / filename> -s columns,metrics
+```
+
+This will sync all metrics and columns for all datasources found in the `<path /filename>` in the
+Superset meta database. This means columns and metrics not specified in YAML will be deleted. If you
+would add tables to columns,metrics those would be synchronised as well.
+
+If you don’t supply the sync flag (**-s**) importing will only add and update (override) fields.
+E.g. you can add a verbose_name to the column ds in the table random_time_series from the example
+datasets by saving the following YAML to file and then running the **import_datasources** command.
+
+```yaml
+databases:
+- database_name: main
+  tables:
+  - table_name: random_time_series
+    columns:
+    - column_name: ds
+      verbose_name: datetime
+```

docs/versioned_docs/version-6.0.0/configuration/map-tiles.mdx

@@ -0,0 +1,78 @@
+---
+title: Map Tiles
+sidebar_position: 12
+version: 1
+---
+
+# Map tiles
+
+Superset uses OSM and Mapbox tiles by default. OSM is free but you still need setting your MAPBOX_API_KEY if you want to use mapbox maps.
+
+## Setting map tiles
+
+Map tiles can be set with `DECKGL_BASE_MAP` in your `superset_config.py` or `superset_config_docker.py`
+For adding your own map tiles, you can use the following format.
+
+```python
+DECKGL_BASE_MAP = [
+    ['tile://https://your_personal_url/{z}/{x}/{y}.png', 'MyTile']
+]
+```
+Openstreetmap tiles url can be added without prefix.
+```python
+DECKGL_BASE_MAP = [
+    ['https://c.tile.openstreetmap.org/{z}/{x}/{y}.png', 'OpenStreetMap']
+]
+```
+
+Default values are:
+```python
+DECKGL_BASE_MAP = [
+    ['https://tile.openstreetmap.org/{z}/{x}/{y}.png', 'Streets (OSM)'],
+    ['https://tile.osm.ch/osm-swiss-style/{z}/{x}/{y}.png', 'Topography (OSM)'],
+    ['mapbox://styles/mapbox/streets-v9', 'Streets'],
+    ['mapbox://styles/mapbox/dark-v9', 'Dark'],
+    ['mapbox://styles/mapbox/light-v9', 'Light'],
+    ['mapbox://styles/mapbox/satellite-streets-v9', 'Satellite Streets'],
+    ['mapbox://styles/mapbox/satellite-v9', 'Satellite'],
+    ['mapbox://styles/mapbox/outdoors-v9', 'Outdoors'],
+]
+```
+
+It is possible to set only mapbox by removing osm tiles and other way around.
+
+:::warning
+Setting `DECKGL_BASE_MAP` overwrite default values
+:::
+
+After defining your map tiles, set them in these variables:
+- `CORS_OPTIONS`
+- `connect-src` of `TALISMAN_CONFIG` and `TALISMAN_CONFIG_DEV` variables.
+
+```python
+ENABLE_CORS = True
+CORS_OPTIONS: dict[Any, Any] = {
+    "origins": [
+        "https://tile.openstreetmap.org",
+        "https://tile.osm.ch",
+        "https://your_personal_url/{z}/{x}/{y}.png",
+    ]
+}
+
+.
+.
+
+TALISMAN_CONFIG = {
+    "content_security_policy": {
+        ...
+        "connect-src": [
+            "'self'",
+            "https://api.mapbox.com",
+            "https://events.mapbox.com",
+            "https://tile.openstreetmap.org",
+            "https://tile.osm.ch",
+            "https://your_personal_url/{z}/{x}/{y}.png",
+        ],
+        ...
+}
+```

docs/versioned_docs/version-6.0.0/configuration/networking-settings.mdx

@@ -0,0 +1,141 @@
+---
+title: Network and Security Settings
+sidebar_position: 7
+version: 1
+---
+
+# Network and Security Settings
+
+## CORS
+
+
+:::note
+In Superset versions prior to `5.x` you have to install to install `flask-cors` with `pip install flask-cors` to enable CORS support.
+:::
+
+
+The following keys in `superset_config.py` can be specified to configure CORS:
+
+- `ENABLE_CORS`: Must be set to `True` in order to enable CORS
+- `CORS_OPTIONS`: options passed to Flask-CORS
+  ([documentation](https://flask-cors.readthedocs.io/en/latest/api.html#extension))
+
+## HTTP headers
+
+Note that Superset bundles [flask-talisman](https://pypi.org/project/talisman/)
+Self-described as a small Flask extension that handles setting HTTP headers that can help
+protect against a few common web application security issues.
+
+## HTML Embedding of Dashboards and Charts
+
+There are two ways to embed a dashboard: Using the [SDK](https://www.npmjs.com/package/@superset-ui/embedded-sdk) or embedding a direct link. Note that in the latter case everybody who knows the link is able to access the dashboard.
+
+### Embedding a Public Direct Link to a Dashboard
+
+This works by first changing the content security policy (CSP) of [flask-talisman](https://github.com/GoogleCloudPlatform/flask-talisman) to allow for certain domains to display Superset content. Then a dashboard can be made publicly accessible, i.e. **bypassing authentication**. Once made public, the dashboard's URL can be added to an iframe in another website's HTML code.
+
+#### Changing flask-talisman CSP
+
+Add to `superset_config.py` the entire `TALISMAN_CONFIG` section from `config.py` and include a `frame-ancestors` section:
+
+```python
+TALISMAN_ENABLED = True
+TALISMAN_CONFIG = {
+    "content_security_policy": {
+    ...
+ "frame-ancestors": ["*.my-domain.com", "*.another-domain.com"],
+    ...
+```
+
+Restart Superset for this configuration change to take effect.
+
+#### Making a Dashboard Public
+
+1. Add the `'DASHBOARD_RBAC': True` [Feature Flag](https://github.com/apache/superset/blob/master/RESOURCES/FEATURE_FLAGS.md) to `superset_config.py`
+2. Add the `Public` role to your dashboard as described [here](https://superset.apache.org/docs/using-superset/creating-your-first-dashboard/#manage-access-to-dashboards)
+
+#### Embedding a Public Dashboard
+
+Now anybody can directly access the dashboard's URL. You can embed it in an iframe like so:
+
+```html
+<iframe
+  width="600"
+  height="400"
+  seamless
+  frameBorder="0"
+  scrolling="no"
+  src="https://superset.my-domain.com/superset/dashboard/10/?standalone=1&height=400"
+>
+</iframe>
+```
+
+#### Embedding a Chart
+
+A chart's embed code can be generated by going to a chart's edit view and then clicking at the top right on `...` > `Share` > `Embed code`
+
+### Enabling Embedding via the SDK
+
+Clicking on `...` next to `EDIT DASHBOARD` on the top right of the dashboard's overview page should yield a drop-down menu including the entry "Embed dashboard".
+
+To enable this entry, add the following line to the `.env` file:
+
+```text
+SUPERSET_FEATURE_EMBEDDED_SUPERSET=true
+```
+
+## CSRF settings
+
+Similarly, [flask-wtf](https://flask-wtf.readthedocs.io/en/0.15.x/config/) is used to manage
+some CSRF configurations. If you need to exempt endpoints from CSRF (e.g. if you are
+running a custom auth postback endpoint), you can add the endpoints to `WTF_CSRF_EXEMPT_LIST`:
+
+## SSH Tunneling
+
+1. Turn on feature flag
+    - Change [`SSH_TUNNELING`](https://github.com/apache/superset/blob/eb8386e3f0647df6d1bbde8b42073850796cc16f/superset/config.py#L489) to `True`
+    - If you want to add more security when establishing the tunnel we allow users to overwrite the `SSHTunnelManager` class [here](https://github.com/apache/superset/blob/eb8386e3f0647df6d1bbde8b42073850796cc16f/superset/config.py#L507)
+    - You can also set the [`SSH_TUNNEL_LOCAL_BIND_ADDRESS`](https://github.com/apache/superset/blob/eb8386e3f0647df6d1bbde8b42073850796cc16f/superset/config.py#L508) this the host address where the tunnel will be accessible on your VPC
+
+2. Create database w/ ssh tunnel enabled
+    - With the feature flag enabled you should now see ssh tunnel toggle.
+    - Click the toggle to enable SSH tunneling and add your credentials accordingly.
+        - Superset allows for two different types of authentication (Basic + Private Key). These credentials should come from your service provider.
+
+3. Verify data is flowing
+    - Once SSH tunneling has been enabled, go to SQL Lab and write a query to verify data is properly flowing.
+
+## Domain Sharding
+
+:::note
+Domain Sharding is deprecated as of Superset 5.0.0, and will be removed in Superset 6.0.0. Please Enable HTTP2 to keep more open connections per domain.
+:::
+
+Chrome allows up to 6 open connections per domain at a time. When there are more than 6 slices in
+dashboard, a lot of time fetch requests are queued up and wait for next available socket.
+[PR 5039](https://github.com/apache/superset/pull/5039) adds domain sharding to Superset,
+and this feature will be enabled by configuration only (by default Superset doesn’t allow
+cross-domain request).
+
+Add the following setting in your `superset_config.py` file:
+
+- `SUPERSET_WEBSERVER_DOMAINS`: list of allowed hostnames for domain sharding feature.
+
+Please create your domain shards as subdomains of your main domain for authorization to
+work properly on new domains. For Example:
+
+- `SUPERSET_WEBSERVER_DOMAINS=['superset-1.mydomain.com','superset-2.mydomain.com','superset-3.mydomain.com','superset-4.mydomain.com']`
+
+or add the following setting in your `superset_config.py` file if domain shards are not subdomains of main domain.
+
+- `SESSION_COOKIE_DOMAIN = '.mydomain.com'`
+
+## Middleware
+
+Superset allows you to add your own middleware. To add your own middleware, update the
+`ADDITIONAL_MIDDLEWARE` key in your `superset_config.py`. `ADDITIONAL_MIDDLEWARE` should be a list
+of your additional middleware classes.
+
+For example, to use `AUTH_REMOTE_USER` from behind a proxy server like nginx, you have to add a
+simple middleware class to add the value of `HTTP_X_PROXY_REMOTE_USER` (or any other custom header
+from the proxy) to Gunicorn’s `REMOTE_USER` environment variable.

docs/versioned_docs/version-6.0.0/configuration/sql-templating.mdx

@@ -0,0 +1,535 @@
+---
+title: SQL Templating
+hide_title: true
+sidebar_position: 5
+version: 1
+---
+
+# SQL Templating
+
+## Jinja Templates
+
+SQL Lab and Explore supports [Jinja templating](https://jinja.palletsprojects.com/en/2.11.x/) in queries.
+To enable templating, the `ENABLE_TEMPLATE_PROCESSING` [feature flag](/docs/configuration/configuring-superset#feature-flags) needs to be enabled in
+`superset_config.py`. When templating is enabled, python code can be embedded in virtual datasets and
+in Custom SQL in the filter and metric controls in Explore. By default, the following variables are
+made available in the Jinja context:
+
+- `columns`: columns which to group by in the query
+- `filter`: filters applied in the query
+- `from_dttm`: start `datetime` value from the selected time range (`None` if undefined) (deprecated beginning in version 5.0, use `get_time_filter` instead)
+- `to_dttm`: end `datetime` value from the selected time range (`None` if undefined). (deprecated beginning in version 5.0, use `get_time_filter` instead)
+- `groupby`: columns which to group by in the query (deprecated)
+- `metrics`: aggregate expressions in the query
+- `row_limit`: row limit of the query
+- `row_offset`: row offset of the query
+- `table_columns`: columns available in the dataset
+- `time_column`: temporal column of the query (`None` if undefined)
+- `time_grain`: selected time grain (`None` if undefined)
+
+For example, to add a time range to a virtual dataset, you can write the following:
+
+```sql
+SELECT *
+FROM tbl
+WHERE dttm_col > '{{ from_dttm }}' and dttm_col < '{{ to_dttm }}'
+```
+
+You can also use [Jinja's logic](https://jinja.palletsprojects.com/en/2.11.x/templates/#tests)
+to make your query robust to clearing the timerange filter:
+
+```sql
+SELECT *
+FROM tbl
+WHERE (
+    {% if from_dttm is not none %}
+        dttm_col > '{{ from_dttm }}' AND
+    {% endif %}
+    {% if to_dttm is not none %}
+        dttm_col < '{{ to_dttm }}' AND
+    {% endif %}
+    1 = 1
+)
+```
+
+The `1 = 1` at the end ensures a value is present for the `WHERE` clause even when
+the time filter is not set. For many database engines, this could be replaced with `true`.
+
+Note that the Jinja parameters are called within _double_ brackets in the query and with
+_single_ brackets in the logic blocks.
+
+To add custom functionality to the Jinja context, you need to overload the default Jinja
+context in your environment by defining the `JINJA_CONTEXT_ADDONS` in your superset configuration
+(`superset_config.py`). Objects referenced in this dictionary are made available for users to use
+where the Jinja context is made available.
+
+```python
+JINJA_CONTEXT_ADDONS = {
+    'my_crazy_macro': lambda x: x*2,
+}
+```
+
+Default values for jinja templates can be specified via `Parameters` menu in the SQL Lab user interface.
+In the UI you can assign a set of parameters as JSON
+
+```json
+{
+  "my_table": "foo"
+}
+```
+
+The parameters become available in your SQL (example: `SELECT * FROM {{ my_table }}` ) by using Jinja templating syntax.
+SQL Lab template parameters are stored with the dataset as `TEMPLATE PARAMETERS`.
+
+There is a special ``_filters`` parameter which can be used to test filters used in the jinja template.
+
+```json
+{
+  "_filters": [
+    {
+      "col": "action_type",
+      "op": "IN",
+      "val": ["sell", "buy"]
+    }
+  ]
+}
+```
+
+```sql
+SELECT action, count(*) as times
+FROM logs
+WHERE action in {{ filter_values('action_type')|where_in }}
+GROUP BY action
+```
+
+Note ``_filters`` is not stored with the dataset. It's only used within the SQL Lab UI.
+
+Besides default Jinja templating, SQL lab also supports self-defined template processor by setting
+the `CUSTOM_TEMPLATE_PROCESSORS` in your superset configuration. The values in this dictionary
+overwrite the default Jinja template processors of the specified database engine. The example below
+configures a custom presto template processor which implements its own logic of processing macro
+template with regex parsing. It uses the `$` style macro instead of `{{ }}` style in Jinja
+templating.
+
+By configuring it with `CUSTOM_TEMPLATE_PROCESSORS`, a SQL template on a presto database is
+processed by the custom one rather than the default one.
+
+```python
+def DATE(
+    ts: datetime, day_offset: SupportsInt = 0, hour_offset: SupportsInt = 0
+) -> str:
+    """Current day as a string."""
+    day_offset, hour_offset = int(day_offset), int(hour_offset)
+    offset_day = (ts + timedelta(days=day_offset, hours=hour_offset)).date()
+    return str(offset_day)
+
+class CustomPrestoTemplateProcessor(PrestoTemplateProcessor):
+    """A custom presto template processor."""
+
+    engine = "presto"
+
+    def process_template(self, sql: str, **kwargs) -> str:
+        """Processes a sql template with $ style macro using regex."""
+        # Add custom macros functions.
+        macros = {
+            "DATE": partial(DATE, datetime.utcnow())
+        }  # type: Dict[str, Any]
+        # Update with macros defined in context and kwargs.
+        macros.update(self.context)
+        macros.update(kwargs)
+
+        def replacer(match):
+            """Expand $ style macros with corresponding function calls."""
+            macro_name, args_str = match.groups()
+            args = [a.strip() for a in args_str.split(",")]
+            if args == [""]:
+                args = []
+            f = macros[macro_name[1:]]
+            return f(*args)
+
+        macro_names = ["$" + name for name in macros.keys()]
+        pattern = r"(%s)\s*\(([^()]*)\)" % "|".join(map(re.escape, macro_names))
+        return re.sub(pattern, replacer, sql)
+
+CUSTOM_TEMPLATE_PROCESSORS = {
+    CustomPrestoTemplateProcessor.engine: CustomPrestoTemplateProcessor
+}
+```
+
+SQL Lab also includes a live query validation feature with pluggable backends. You can configure
+which validation implementation is used with which database engine by adding a block like the
+following to your configuration file:
+
+```python
+FEATURE_FLAGS = {
+    'SQL_VALIDATORS_BY_ENGINE': {
+        'presto': 'PrestoDBSQLValidator',
+    }
+}
+```
+
+The available validators and names can be found in
+[sql_validators](https://github.com/apache/superset/tree/master/superset/sql_validators).
+
+## Available Macros
+
+In this section, we'll walkthrough the pre-defined Jinja macros in Superset.
+
+**Current Username**
+
+The `{{ current_username() }}` macro returns the `username` of the currently logged in user.
+
+If you have caching enabled in your Superset configuration, then by default the `username` value will be used
+by Superset when calculating the cache key. A cache key is a unique identifier that determines if there's a
+cache hit in the future and Superset can retrieve cached data.
+
+You can disable the inclusion of the `username` value in the calculation of the
+cache key by adding the following parameter to your Jinja code:
+
+```python
+{{ current_username(add_to_cache_keys=False) }}
+```
+
+**Current User ID**
+
+The `{{ current_user_id() }}` macro returns the account ID of the currently logged in user.
+
+If you have caching enabled in your Superset configuration, then by default the account `id` value will be used
+by Superset when calculating the cache key. A cache key is a unique identifier that determines if there's a
+cache hit in the future and Superset can retrieve cached data.
+
+You can disable the inclusion of the account `id` value in the calculation of the
+cache key by adding the following parameter to your Jinja code:
+
+```python
+{{ current_user_id(add_to_cache_keys=False) }}
+```
+
+**Current User Email**
+
+The `{{ current_user_email() }}` macro returns the email address of the currently logged in user.
+
+If you have caching enabled in your Superset configuration, then by default the email address value will be used
+by Superset when calculating the cache key. A cache key is a unique identifier that determines if there's a
+cache hit in the future and Superset can retrieve cached data.
+
+You can disable the inclusion of the email value in the calculation of the
+cache key by adding the following parameter to your Jinja code:
+
+```python
+{{ current_user_email(add_to_cache_keys=False) }}
+```
+
+**Current User Roles**
+
+The `{{ current_user_roles() }}` macro returns an array of roles for the logged in user.
+
+If you have caching enabled in your Superset configuration, then by default the roles value will be used
+by Superset when calculating the cache key. A cache key is a unique identifier that determines if there's a
+cache hit in the future and Superset can retrieve cached data.
+
+You can disable the inclusion of the roles value in the calculation of the
+cache key by adding the following parameter to your Jinja code:
+
+```python
+{{ current_user_roles(add_to_cache_keys=False) }}
+```
+
+You can json-stringify the array by adding `|tojson` to your Jinja code:
+```python
+{{ current_user_roles()|tojson }}
+```
+
+You can use the `|where_in` filter to use your roles in a SQL statement. For example, if `current_user_roles()` returns `['admin', 'viewer']`, the following template:
+```python
+SELECT * FROM users WHERE role IN {{ current_user_roles()|where_in }}
+```
+
+Will be rendered as:
+```sql
+SELECT * FROM users WHERE role IN ('admin', 'viewer')
+```
+
+**Current User RLS Rules**
+
+The `{{ current_user_rls_rules() }}` macro returns an array of RLS rules applied to the current dataset for the logged in user.
+
+If you have caching enabled in your Superset configuration, then the list of RLS Rules will be used
+by Superset when calculating the cache key. A cache key is a unique identifier that determines if there's a
+cache hit in the future and Superset can retrieve cached data.
+
+**Custom URL Parameters**
+
+The `{{ url_param('custom_variable') }}` macro lets you define arbitrary URL
+parameters and reference them in your SQL code.
+
+Here's a concrete example:
+
+- You write the following query in SQL Lab:
+
+  ```sql
+  SELECT count(*)
+  FROM ORDERS
+  WHERE country_code = '{{ url_param('countrycode') }}'
+  ```
+
+- You're hosting Superset at the domain www.example.com and you send your
+  coworker in Spain the following SQL Lab URL `www.example.com/superset/sqllab?countrycode=ES`
+  and your coworker in the USA the following SQL Lab URL `www.example.com/superset/sqllab?countrycode=US`
+- For your coworker in Spain, the SQL Lab query will be rendered as:
+
+  ```sql
+  SELECT count(*)
+  FROM ORDERS
+  WHERE country_code = 'ES'
+  ```
+
+- For your coworker in the USA, the SQL Lab query will be rendered as:
+
+  ```sql
+  SELECT count(*)
+  FROM ORDERS
+  WHERE country_code = 'US'
+  ```
+
+**Explicitly Including Values in Cache Key**
+
+The `{{ cache_key_wrapper() }}` function explicitly instructs Superset to add a value to the
+accumulated list of values used in the calculation of the cache key.
+
+This function is only needed when you want to wrap your own custom function return values
+in the cache key. You can gain more context
+[here](https://github.com/apache/superset/blob/efd70077014cbed62e493372d33a2af5237eaadf/superset/jinja_context.py#L133-L148).
+
+Note that this function powers the caching of the `user_id` and `username` values
+in the `current_user_id()` and `current_username()` function calls (if you have caching enabled).
+
+**Filter Values**
+
+You can retrieve the value for a specific filter as a list using `{{ filter_values() }}`.
+
+This is useful if:
+
+- You want to use a filter component to filter a query where the name of filter component column doesn't match the one in the select statement
+- You want to have the ability to filter inside the main query for performance purposes
+
+Here's a concrete example:
+
+```sql
+SELECT action, count(*) as times
+FROM logs
+WHERE
+    action in {{ filter_values('action_type')|where_in }}
+GROUP BY action
+```
+
+There `where_in` filter converts the list of values from `filter_values('action_type')` into a string suitable for an `IN` expression.
+
+**Filters for a Specific Column**
+
+The `{{ get_filters() }}` macro returns the filters applied to a given column. In addition to
+returning the values (similar to how `filter_values()` does), the `get_filters()` macro
+returns the operator specified in the Explore UI.
+
+This is useful if:
+
+- You want to handle more than the IN operator in your SQL clause
+- You want to handle generating custom SQL conditions for a filter
+- You want to have the ability to filter inside the main query for speed purposes
+
+Here's a concrete example:
+
+```sql
+ WITH RECURSIVE
+    superiors(employee_id, manager_id, full_name, level, lineage) AS (
+    SELECT
+        employee_id,
+        manager_id,
+        full_name,
+    1 as level,
+    employee_id as lineage
+    FROM
+        employees
+    WHERE
+    1=1
+
+    {# Render a blank line #}
+    {%- for filter in get_filters('full_name', remove_filter=True) -%}
+
+    {%- if filter.get('op') == 'IN' -%}
+        AND
+        full_name IN {{ filter.get('val')|where_in }}
+    {%- endif -%}
+
+    {%- if filter.get('op') == 'LIKE' -%}
+        AND
+        full_name LIKE {{ "'" + filter.get('val') + "'" }}
+    {%- endif -%}
+
+    {%- endfor -%}
+    UNION ALL
+        SELECT
+            e.employee_id,
+            e.manager_id,
+            e.full_name,
+    s.level + 1 as level,
+    s.lineage
+        FROM
+            employees e,
+        superiors s
+        WHERE s.manager_id = e.employee_id
+    )
+
+    SELECT
+    employee_id, manager_id, full_name, level, lineage
+    FROM
+    superiors
+    order by lineage, level
+```
+
+**Time Filter**
+
+The `{{ get_time_filter() }}` macro returns the time filter applied to a specific column. This is useful if you want
+to handle time filters inside the virtual dataset, as by default the time filter is placed on the outer query. This can
+considerably improve performance, as many databases and query engines are able to optimize the query better
+if the temporal filter is placed on the inner query, as opposed to the outer query.
+
+The macro takes the following parameters:
+
+- `column`: Name of the temporal column. Leave undefined to reference the time range from a Dashboard Native Time Range
+  filter (when present).
+- `default`: The default value to fall back to if the time filter is not present, or has the value `No filter`
+- `target_type`: The target temporal type as recognized by the target  database (e.g. `TIMESTAMP`, `DATE` or
+  `DATETIME`). If `column` is defined, the format will default to the type of the column. This is used to produce
+  the format of the `from_expr` and `to_expr` properties of the returned `TimeFilter` object.
+- `strftime`: format using the `strftime` method of `datetime` for custom time formatting.
+  ([see docs for valid format codes](https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes)).
+  When defined `target_type` will be ignored.
+- `remove_filter`: When set to true, mark the filter as processed, removing it from the outer query. Useful when a
+  filter should only apply to the inner query.
+
+The return type has the following properties:
+
+- `from_expr`: the start of the time filter (if any)
+- `to_expr`: the end of the time filter (if any)
+- `time_range`: The applied time range
+
+Here's a concrete example using the `logs` table from the Superset metastore:
+
+```
+{% set time_filter = get_time_filter("dttm", remove_filter=True) %}
+{% set from_expr = time_filter.from_expr %}
+{% set to_expr = time_filter.to_expr %}
+{% set time_range = time_filter.time_range %}
+SELECT
+  *,
+  '{{ time_range }}' as time_range
+FROM logs
+{% if from_expr or to_expr %}WHERE 1 = 1
+{% if from_expr %}AND dttm >= {{ from_expr }}{% endif %}
+{% if to_expr %}AND dttm < {{ to_expr }}{% endif %}
+{% endif %}
+```
+
+Assuming we are creating a table chart with a simple `COUNT(*)` as the metric with a time filter `Last week` on the
+`dttm` column, this would render the following query on Postgres (note the formatting of the temporal filters, and
+the absence of time filters on the outer query):
+
+```
+SELECT COUNT(*) AS count
+FROM
+  (SELECT *,
+          'Last week' AS time_range
+   FROM public.logs
+   WHERE 1 = 1
+     AND dttm >= TO_TIMESTAMP('2024-08-27 00:00:00.000000', 'YYYY-MM-DD HH24:MI:SS.US')
+     AND dttm < TO_TIMESTAMP('2024-09-03 00:00:00.000000', 'YYYY-MM-DD HH24:MI:SS.US')) AS virtual_table
+ORDER BY count DESC
+LIMIT 1000;
+```
+
+When using the `default` parameter, the templated query can be simplified, as the endpoints will always be defined
+(to use a fixed time range, you can also use something like `default="2024-08-27 : 2024-09-03"`)
+
+```
+{% set time_filter = get_time_filter("dttm", default="Last week", remove_filter=True) %}
+SELECT
+  *,
+  '{{ time_filter.time_range }}' as time_range
+FROM logs
+WHERE
+  dttm >= {{ time_filter.from_expr }}
+  AND dttm < {{ time_filter.to_expr }}
+```
+
+**Datasets**
+
+It's possible to query physical and virtual datasets using the `dataset` macro. This is useful if you've defined computed columns and metrics on your datasets, and want to reuse the definition in adhoc SQL Lab queries.
+
+To use the macro, first you need to find the ID of the dataset. This can be done by going to the view showing all the datasets, hovering over the dataset you're interested in, and looking at its URL. For example, if the URL for a dataset is https://superset.example.org/explore/?dataset_type=table&dataset_id=42 its ID is 42.
+
+Once you have the ID you can query it as if it were a table:
+
+```sql
+SELECT * FROM {{ dataset(42) }} LIMIT 10
+```
+
+If you want to select the metric definitions as well, in addition to the columns, you need to pass an additional keyword argument:
+
+```sql
+SELECT * FROM {{ dataset(42, include_metrics=True) }} LIMIT 10
+```
+
+Since metrics are aggregations, the resulting SQL expression will be grouped by all non-metric columns. You can specify a subset of columns to group by instead:
+
+```sql
+SELECT * FROM {{ dataset(42, include_metrics=True, columns=["ds", "category"]) }} LIMIT 10
+```
+
+**Metrics**
+
+The `{{ metric('metric_key', dataset_id) }}` macro can be used to retrieve the metric SQL syntax from a dataset. This can be useful for different purposes:
+
+- Override the metric label in the chart level
+- Combine multiple metrics in a calculation
+- Retrieve a metric syntax in SQL lab
+- Re-use metrics across datasets
+
+This macro avoids copy/paste, allowing users to centralize the metric definition in the dataset layer.
+
+The `dataset_id` parameter is optional, and if not provided Superset will use the current dataset from context (for example, when using this macro in the Chart Builder, by default the `macro_key` will be searched in the dataset powering the chart).
+The parameter can be used in SQL Lab, or when fetching a metric from another dataset.
+
+## Available Filters
+
+Superset supports [builtin filters from the Jinja2 templating package](https://jinja.palletsprojects.com/en/stable/templates/#builtin-filters). Custom filters have also been implemented:
+
+**Where In**
+Parses a list into a SQL-compatible statement. This is useful with macros that return an array (for example the `filter_values` macro):
+
+```
+Dashboard filter with "First", "Second" and "Third" options selected
+{{ filter_values('column') }} => ["First", "Second", "Third"]
+{{ filter_values('column')|where_in }} => ('First', 'Second', 'Third')
+```
+
+By default, this filter returns `()` (as a string) in case the value is null. The `default_to_none` parameter can be se to `True` to return null in this case:
+
+```
+Dashboard filter without any value applied
+{{ filter_values('column') }} => ()
+{{ filter_values('column')|where_in(default_to_none=True) }} => None
+```
+
+**To Datetime**
+
+Loads a string as a `datetime` object. This is useful when performing date operations. For example:
+```
+{% set from_expr = get_time_filter("dttm", strftime="%Y-%m-%d").from_expr %}
+{% set to_expr = get_time_filter("dttm", strftime="%Y-%m-%d").to_expr %}
+{% if (to_expr|to_datetime(format="%Y-%m-%d") - from_expr|to_datetime(format="%Y-%m-%d")).days > 100 %}
+   do something
+{% else %}
+   do something else
+{% endif %}
+```

docs/versioned_docs/version-6.0.0/configuration/theming.mdx

@@ -0,0 +1,192 @@
+---
+title: Theming
+hide_title: true
+sidebar_position: 12
+version: 1
+---
+# Theming Superset
+
+:::note
+apache-superset>=6.0
+:::
+
+Superset now rides on **Ant Design v5's token-based theming**.
+Every Antd token works, plus a handful of Superset-specific ones for charts and dashboard chrome.
+
+## Managing Themes via UI
+
+Superset includes a built-in **Theme Management** interface accessible from the admin menu under **Settings > Themes**.
+
+### Creating a New Theme
+
+1. Navigate to **Settings > Themes** in the Superset interface
+2. Click **+ Theme** to create a new theme
+3. Use the [Ant Design Theme Editor](https://ant.design/theme-editor) to design your theme:
+   - Design your palette, typography, and component overrides
+   - Open the `CONFIG` modal and copy the JSON configuration
+4. Paste the JSON into the theme definition field in Superset
+5. Give your theme a descriptive name and save
+
+You can also extend with Superset-specific tokens (documented in the default theme object) before you import.
+
+### System Theme Administration
+
+When `ENABLE_UI_THEME_ADMINISTRATION = True` is configured, administrators can manage system-wide themes directly from the UI:
+
+#### Setting System Themes
+- **System Default Theme**: Click the sun icon on any theme to set it as the system-wide default
+- **System Dark Theme**: Click the moon icon on any theme to set it as the system dark mode theme
+- **Automatic OS Detection**: When both default and dark themes are set, Superset automatically detects and applies the appropriate theme based on OS preferences
+
+#### Managing System Themes
+- System themes are indicated with special badges in the theme list
+- Only administrators with write permissions can modify system theme settings
+- Removing a system theme designation reverts to configuration file defaults
+
+### Applying Themes to Dashboards
+
+Once created, themes can be applied to individual dashboards:
+- Edit any dashboard and select your custom theme from the theme dropdown
+- Each dashboard can have its own theme, allowing for branded or context-specific styling
+
+## Configuration Options
+
+### Python Configuration
+
+Configure theme behavior via `superset_config.py`:
+
+```python
+# Enable UI-based theme administration for admins
+ENABLE_UI_THEME_ADMINISTRATION = True
+
+# Optional: Set initial default themes via configuration
+# These can be overridden via the UI when ENABLE_UI_THEME_ADMINISTRATION = True
+THEME_DEFAULT = {
+    "token": {
+        "colorPrimary": "#2893B3",
+        "colorSuccess": "#5ac189",
+        # ... your theme JSON configuration
+    }
+}
+
+# Optional: Dark theme configuration
+THEME_DARK = {
+    "algorithm": "dark",
+    "token": {
+        "colorPrimary": "#2893B3",
+        # ... your dark theme overrides
+    }
+}
+
+# To force a single theme on all users, set THEME_DARK = None
+# When both themes are defined (via UI or config):
+# - Users can manually switch between themes
+# - OS preference detection is automatically enabled
+```
+
+### Migration from Configuration to UI
+
+When `ENABLE_UI_THEME_ADMINISTRATION = True`:
+
+1. System themes set via the UI take precedence over configuration file settings
+2. The UI shows which themes are currently set as system defaults
+3. Administrators can change system themes without restarting Superset
+4. Configuration file themes serve as fallbacks when no UI themes are set
+
+### Copying Themes Between Systems
+
+To export a theme for use in configuration files or another instance:
+
+1. Navigate to **Settings > Themes** and click the export icon on your desired theme
+2. Extract the JSON configuration from the exported YAML file
+3. Use this JSON in your `superset_config.py` or import it into another Superset instance
+
+## Theme Development Workflow
+
+1. **Design**: Use the [Ant Design Theme Editor](https://ant.design/theme-editor) to iterate on your design
+2. **Test**: Create themes in Superset's CRUD interface for testing
+3. **Apply**: Assign themes to specific dashboards or configure instance-wide
+4. **Iterate**: Modify theme JSON directly in the CRUD interface or re-import from the theme editor
+
+## Custom Fonts
+
+Superset supports custom fonts through runtime configuration, allowing you to use branded or custom typefaces without rebuilding the application.
+
+### Configuring Custom Fonts
+
+Add font URLs to your `superset_config.py`:
+
+```python
+# Load fonts from Google Fonts, Adobe Fonts, or self-hosted sources
+CUSTOM_FONT_URLS = [
+    "https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap",
+    "https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500&display=swap",
+]
+
+# Update CSP to allow font sources
+TALISMAN_CONFIG = {
+    "content_security_policy": {
+        "font-src": ["'self'", "https://fonts.googleapis.com", "https://fonts.gstatic.com"],
+        "style-src": ["'self'", "'unsafe-inline'", "https://fonts.googleapis.com"],
+    }
+}
+```
+
+### Using Custom Fonts in Themes
+
+Once configured, reference the fonts in your theme configuration:
+
+```python
+THEME_DEFAULT = {
+    "token": {
+        "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
+        "fontFamilyCode": "JetBrains Mono, Monaco, monospace",
+        # ... other theme tokens
+    }
+}
+```
+
+Or in the CRUD interface theme JSON:
+
+```json
+{
+  "token": {
+    "fontFamily": "Inter, -apple-system, BlinkMacSystemFont, sans-serif",
+    "fontFamilyCode": "JetBrains Mono, Monaco, monospace"
+  }
+}
+```
+
+### Font Sources
+
+- **Google Fonts**: Free, CDN-hosted fonts with wide variety
+- **Adobe Fonts**: Premium fonts (requires subscription and kit ID)
+- **Self-hosted**: Place font files in `/static/assets/fonts/` and reference via CSS
+
+This feature works with the stock Docker image - no custom build required!
+
+## Advanced Features
+
+- **System Themes**: Manage system-wide default and dark themes via UI or configuration
+- **Per-Dashboard Theming**: Each dashboard can have its own visual identity
+- **JSON Editor**: Edit theme configurations directly within Superset's interface
+- **Custom Fonts**: Load external fonts via configuration without rebuilding
+- **OS Dark Mode Detection**: Automatically switches themes based on system preferences
+- **Theme Import/Export**: Share themes between instances via YAML files
+
+## API Access
+
+For programmatic theme management, Superset provides REST endpoints:
+
+- `GET /api/v1/theme/` - List all themes
+- `POST /api/v1/theme/` - Create a new theme
+- `PUT /api/v1/theme/{id}` - Update a theme
+- `DELETE /api/v1/theme/{id}` - Delete a theme
+- `PUT /api/v1/theme/{id}/set_system_default` - Set as system default theme (admin only)
+- `PUT /api/v1/theme/{id}/set_system_dark` - Set as system dark theme (admin only)
+- `DELETE /api/v1/theme/unset_system_default` - Remove system default designation
+- `DELETE /api/v1/theme/unset_system_dark` - Remove system dark designation
+- `GET /api/v1/theme/export/` - Export themes as YAML
+- `POST /api/v1/theme/import/` - Import themes from YAML
+
+These endpoints require appropriate permissions and are subject to RBAC controls.

docs/versioned_docs/version-6.0.0/configuration/timezones.mdx

@@ -0,0 +1,50 @@
+---
+title: Timezones
+hide_title: true
+sidebar_position: 6
+version: 1
+---
+
+# Timezones
+
+There are four distinct timezone components which relate to Apache Superset,
+
+1. The timezone that the underlying data is encoded in.
+2. The timezone of the database engine.
+3. The timezone of the Apache Superset backend.
+4. The timezone of the Apache Superset client.
+
+where if a temporal field (`DATETIME`, `TIME`, `TIMESTAMP`, etc.) does not explicitly define a timezone it defaults to the underlying timezone of the component.
+
+To help make the problem somewhat tractable—given that Apache Superset has no control on either how the data is ingested (1) or the timezone of the client (4)—from a consistency standpoint it is highly recommended that both (2) and (3) are configured to use the same timezone with a strong preference given to [UTC](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) to ensure temporal fields without an explicit timestamp are not incorrectly coerced into the wrong timezone. Actually Apache Superset currently has implicit assumptions that timestamps are in UTC and thus configuring (3) to a non-UTC timezone could be problematic.
+
+To strive for data consistency (regardless of the timezone of the client) the Apache Superset backend tries to ensure that any timestamp sent to the client has an explicit (or semi-explicit as in the case with [Epoch time](https://en.wikipedia.org/wiki/Unix_time) which is always in reference to UTC) timezone encoded within.
+
+The challenge however lies with the slew of [database engines](/docs/configuration/databases#installing-drivers-in-docker-images) which Apache Superset supports and various inconsistencies between their [Python Database API (DB-API)](https://www.python.org/dev/peps/pep-0249/) implementations combined with the fact that we use [Pandas](https://pandas.pydata.org/) to read SQL into a DataFrame prior to serializing to JSON. Regrettably Pandas ignores the DB-API [type_code](https://www.python.org/dev/peps/pep-0249/#type-objects) relying by default on the underlying Python type returned by the DB-API. Currently only a subset of the supported database engines work correctly with Pandas, i.e., ensuring timestamps without an explicit timestamp are serializd to JSON with the server timezone, thus guaranteeing the client will display timestamps in a consistent manner irrespective of the client's timezone.
+
+For example the following is a comparison of MySQL and Presto,
+
+```python
+import pandas as pd
+from sqlalchemy import create_engine
+
+pd.read_sql_query(
+    sql="SELECT TIMESTAMP('2022-01-01 00:00:00') AS ts",
+    con=create_engine("mysql://root@localhost:3360"),
+).to_json()
+
+pd.read_sql_query(
+    sql="SELECT TIMESTAMP '2022-01-01 00:00:00' AS ts",
+    con=create_engine("presto://localhost:8080"),
+).to_json()
+```
+
+which outputs `{"ts":{"0":1640995200000}}` (which infers the UTC timezone per the Epoch time definition) and `{"ts":{"0":"2022-01-01 00:00:00.000"}}` (without an explicit timezone) respectively and thus are treated differently in JavaScript:
+
+```js
+new Date(1640995200000)
+> Sat Jan 01 2022 13:00:00 GMT+1300 (New Zealand Daylight Time)
+
+new Date("2022-01-01 00:00:00.000")
+> Sat Jan 01 2022 00:00:00 GMT+1300 (New Zealand Daylight Time)
+```

docs/versioned_docs/version-6.0.0/contributing/contributing.mdx

@@ -0,0 +1,138 @@
+---
+title: Contributing to Superset
+sidebar_position: 1
+version: 1
+---
+
+# Contributing to Superset
+
+Superset is an [Apache Software foundation](https://www.apache.org/theapacheway/index.html) project.
+The core contributors (or committers) to Superset communicate primarily in the following channels (
+which can be joined by anyone):
+
+- [Mailing list](https://lists.apache.org/list.html?dev@superset.apache.org)
+- [Apache Superset Slack community](http://bit.ly/join-superset-slack)
+- [GitHub issues](https://github.com/apache/superset/issues)
+- [GitHub pull requests](https://github.com/apache/superset/pulls)
+- [GitHub discussions](https://github.com/apache/superset/discussions)
+- [Superset Community Calendar](https://superset.apache.org/community)
+
+More references:
+
+- [Superset Wiki (code guidelines and additional resources)](https://github.com/apache/superset/wiki)
+
+## Orientation
+
+Here's a list of repositories that contain Superset-related packages:
+
+- [apache/superset](https://github.com/apache/superset)
+  is the main repository containing the `apache_superset` Python package
+  distributed on
+  [pypi](https://pypi.org/project/apache_superset/). This repository
+  also includes Superset's main TypeScript/JavaScript bundles and react apps under
+  the [superset-frontend](https://github.com/apache/superset/tree/master/superset-frontend)
+  folder.
+- [github.com/apache-superset](https://github.com/apache-superset) is the
+  GitHub organization under which we manage Superset-related
+  small tools, forks and Superset-related experimental ideas.
+
+## Types of Contributions
+
+### Report Bug
+
+The best way to report a bug is to file an issue on GitHub. Please include:
+
+- Your operating system name and version.
+- Superset version.
+- Detailed steps to reproduce the bug.
+- Any details about your local setup that might be helpful in troubleshooting.
+
+When posting Python stack traces, please quote them using
+[Markdown blocks](https://help.github.com/articles/creating-and-highlighting-code-blocks/).
+
+_Please note that feature requests opened as GitHub Issues will be moved to Discussions._
+
+### Submit Ideas or Feature Requests
+
+The best way is to start an ["Ideas" Discussion thread](https://github.com/apache/superset/discussions/categories/ideas) on GitHub:
+
+- Explain in detail how it would work.
+- Keep the scope as narrow as possible, to make it easier to implement.
+- Remember that this is a volunteer-driven project, and that your contributions are as welcome as anyone's :)
+
+To propose large features or major changes to codebase, and help usher in those changes, please create a **Superset Improvement Proposal (SIP)**. See template from [SIP-0](https://github.com/apache/superset/issues/5602)
+
+### Fix Bugs
+
+Look through the GitHub issues. Issues tagged with `#bug` are
+open to whoever wants to implement them.
+
+### Implement Features
+
+Look through the GitHub issues. Issues tagged with
+`#feature` are open to whoever wants to implement them.
+
+### Improve Documentation
+
+Superset could always use better documentation,
+whether as part of the official Superset docs,
+in docstrings, `docs/*.rst` or even on the web as blog posts or
+articles. See [Documentation](/docs/contributing/howtos#contributing-to-documentation) for more details.
+
+### Add Translations
+
+If you are proficient in a non-English language, you can help translate
+text strings from Superset's UI. You can jump into the existing
+language dictionaries at
+`superset/translations/<language_code>/LC_MESSAGES/messages.po`, or
+even create a dictionary for a new language altogether.
+See [Translating](howtos#contributing-translations) for more details.
+
+### Ask Questions
+
+There is a dedicated [`apache-superset` tag](https://stackoverflow.com/questions/tagged/apache-superset) on [StackOverflow](https://stackoverflow.com/). Please use it when asking questions.
+
+## Types of Contributors
+
+Following the project governance model of the Apache Software Foundation (ASF), Apache Superset has a specific set of contributor roles:
+
+### PMC Member
+
+A Project Management Committee (PMC) member is a person who has been elected by the PMC to help manage the project. PMC members are responsible for the overall health of the project, including community development, release management, and project governance. PMC members are also responsible for the technical direction of the project.
+
+For more information about Apache Project PMCs, please refer to https://www.apache.org/foundation/governance/pmcs.html
+
+### Committer
+
+A committer is a person who has been elected by the PMC to have write access (commit access) to the code repository. They can modify the code, documentation, and website and accept contributions from others.
+
+The official list of committers and PMC members can be found [here](https://projects.apache.org/committee.html?superset).
+
+### Contributor
+
+A contributor is a person who has contributed to the project in any way, including but not limited to code, tests, documentation, issues, and discussions.
+
+> You can also review the Superset project's guidelines for PMC member promotion here: https://github.com/apache/superset/wiki/Guidelines-for-promoting-Superset-Committers-to-the-Superset-PMC
+
+### Security Team
+
+The security team is a selected subset of PMC members, committers and non-committers who are responsible for handling security issues.
+
+New members of the security team are selected by the PMC members in a vote. You can request to be added to the team by sending a message to private@superset.apache.org. However, the team should be small and focused on solving security issues, so the requests will be evaluated on a case-by-case basis and the team size will be kept relatively small, limited to only actively security-focused contributors.
+
+This security team must follow the [ASF vulnerability handling process](https://apache.org/security/committers.html#asf-project-security-for-committers).
+
+Each new security issue is tracked as a JIRA ticket on the [ASF's JIRA Superset security project](https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=588&projectKey=SUPERSETSEC)
+
+Security team members must:
+
+- Have an [ICLA](https://www.apache.org/licenses/contributor-agreements.html) signed with Apache Software Foundation.
+- Not reveal information about pending and unfixed security issues to anyone (including their employers) unless specifically authorised by the security team members, e.g., if the security team agrees that diagnosing and solving an issue requires the involvement of external experts.
+
+A release manager, the contributor overseeing the release of a specific version of Apache Superset, is by default a member of the security team.  However, they are not expected to be active in assessing, discussing, and fixing security issues.
+
+Security team members should also follow these general expectations:
+
+- Actively participate in assessing, discussing, fixing, and releasing security issues in Superset.
+- Avoid discussing security fixes in public forums. Pull request (PR) descriptions should not contain any information about security issues. The corresponding JIRA ticket should contain a link to the PR.
+- Security team members who contribute to a fix may be listed as remediation developers in the CVE report, along with their job affiliation (if they choose to include it).

docs/versioned_docs/version-6.0.0/contributing/guidelines.mdx

@@ -0,0 +1,254 @@
+---
+title: Guidelines
+sidebar_position: 2
+version: 1
+---
+
+## Pull Request Guidelines
+
+A philosophy we would like to strongly encourage is
+
+> Before creating a PR, create an issue.
+
+The purpose is to separate problem from possible solutions.
+
+**Bug fixes:** If you’re only fixing a small bug, it’s fine to submit a pull request right away but we highly recommend filing an issue detailing what you’re fixing. This is helpful in case we don’t accept that specific fix but want to keep track of the issue. Please keep in mind that the project maintainers reserve the rights to accept or reject incoming PRs, so it is better to separate the issue and the code to fix it from each other. In some cases, project maintainers may request you to create a separate issue from PR before proceeding.
+
+**Refactor:** For small refactors, it can be a standalone PR itself detailing what you are refactoring and why. If there are concerns, project maintainers may request you to create a `#SIP` for the PR before proceeding.
+
+**Feature/Large changes:** If you intend to change the public API, or make any non-trivial changes to the implementation, we require you to file a new issue as `#SIP` (Superset Improvement Proposal). This lets us reach an agreement on your proposal before you put significant effort into it. You are welcome to submit a PR along with the SIP (sometimes necessary for demonstration), but we will not review/merge the code until the SIP is approved.
+
+In general, small PRs are always easier to review than large PRs. The best practice is to break your work into smaller independent PRs and refer to the same issue. This will greatly reduce turnaround time.
+
+If you wish to share your work which is not ready to merge yet, create a [Draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/). This will enable maintainers and the CI runner to prioritize mature PR's.
+
+Finally, never submit a PR that will put master branch in broken state. If the PR is part of multiple PRs to complete a large feature and cannot work on its own, you can create a feature branch and merge all related PRs into the feature branch before creating a PR from feature branch to master.
+
+### Protocol
+
+#### Authoring
+
+- Fill in all sections of the PR template.
+- Title the PR with one of the following semantic prefixes (inspired by [Karma](http://karma-runner.github.io/0.10/dev/git-commit-msg.html])):
+
+  - `feat` (new feature)
+  - `fix` (bug fix)
+  - `docs` (changes to the documentation)
+  - `style` (formatting, missing semi colons, etc; no application logic change)
+  - `refactor` (refactoring code)
+  - `test` (adding missing tests, refactoring tests; no application logic change)
+  - `chore` (updating tasks etc; no application logic change)
+  - `perf` (performance-related change)
+  - `build` (build tooling, Docker configuration change)
+  - `ci` (test runner, GitHub Actions workflow changes)
+  - `other` (changes that don't correspond to the above -- should be rare!)
+  - Examples:
+    - `feat: export charts as ZIP files`
+    - `perf(api): improve API info performance`
+    - `fix(chart-api): cached-indicator always shows value is cached`
+
+- Add prefix `[WIP]` to title if not ready for review (WIP = work-in-progress). We recommend creating a PR with `[WIP]` first and remove it once you have passed CI test and read through your code changes at least once.
+- If you believe your PR contributes a potentially breaking change, put a `!` after the semantic prefix but before the colon in the PR title, like so: `feat!: Added foo functionality to bar`
+- **Screenshots/GIFs:** Changes to user interface require before/after screenshots, or GIF for interactions
+  - Recommended capture tools ([Kap](https://getkap.co/), [LICEcap](https://www.cockos.com/licecap/), [Skitch](https://download.cnet.com/Skitch/3000-13455_4-189876.html))
+  - If no screenshot is provided, the committers will mark the PR with `need:screenshot` label and will not review until screenshot is provided.
+- **Dependencies:** Be careful about adding new dependency and avoid unnecessary dependencies.
+  - For Python, include it in `pyproject.toml` denoting any specific restrictions and
+    in `requirements.txt` pinned to a specific version which ensures that the application
+    build is deterministic.
+  - For TypeScript/JavaScript, include new libraries in `package.json`
+- **Tests:** The pull request should include tests, either as doctests, unit tests, or both. Make sure to resolve all errors and test failures. See [Testing](/docs/contributing/howtos#testing) for how to run tests.
+- **Documentation:** If the pull request adds functionality, the docs should be updated as part of the same PR.
+- **CI:** Reviewers will not review the code until all CI tests are passed. Sometimes there can be flaky tests. You can close and open PR to re-run CI test. Please report if the issue persists. After the CI fix has been deployed to `master`, please rebase your PR.
+- **Code coverage:** Please ensure that code coverage does not decrease.
+- Remove `[WIP]` when ready for review. Please note that it may be merged soon after approved so please make sure the PR is ready to merge and do not expect more time for post-approval edits.
+- If the PR was not ready for review and inactive for > 30 days, we will close it due to inactivity. The author is welcome to re-open and update.
+
+#### Reviewing
+
+- Use constructive tone when writing reviews.
+- If there are changes required, state clearly what needs to be done before the PR can be approved.
+- If you are asked to update your pull request with some changes there's no need to create a new one. Push your changes to the same branch.
+- The committers reserve the right to reject any PR and in some cases may request the author to file an issue.
+
+#### Test Environments
+
+- Members of the Apache GitHub org can launch an ephemeral test environment directly on a pull request by creating a comment containing (only) the command `/testenv up`.
+  - Note that org membership must be public in order for this validation to function properly.
+- Feature flags may be set for a test environment by specifying the flag name (prefixed with `FEATURE_`) and value after the command.
+  - Format: `/testenv up FEATURE_<feature flag name>=true|false`
+  - Example: `/testenv up FEATURE_DASHBOARD_NATIVE_FILTERS=true`
+  - Multiple feature flags may be set in single command, separated by whitespace
+- A comment will be created by the workflow script with the address and login information for the ephemeral environment.
+- Test environments may be created once the Docker build CI workflow for the PR has completed successfully.
+- Test environments do not currently update automatically when new commits are added to a pull request.
+- Test environments do not currently support async workers, though this is planned.
+- Running test environments will be shutdown upon closing the pull request.
+
+#### Merging
+
+- At least one approval is required for merging a PR.
+- PR is usually left open for at least 24 hours before merging.
+- After the PR is merged, [close the corresponding issue(s)](https://help.github.com/articles/closing-issues-using-keywords/).
+
+#### Post-merge Responsibility
+
+- Project maintainers may contact the PR author if new issues are introduced by the PR.
+- Project maintainers may revert your changes if a critical issue is found, such as breaking master branch CI.
+
+## Managing Issues and PRs
+
+To handle issues and PRs that are coming in, committers read issues/PRs and flag them with labels to categorize and help contributors spot where to take actions, as contributors usually have different expertises.
+
+Triaging goals
+
+- **For issues:** Categorize, screen issues, flag required actions from authors.
+- **For PRs:** Categorize, flag required actions from authors. If PR is ready for review, flag required actions from reviewers.
+
+First, add **Category labels (a.k.a. hash labels)**. Every issue/PR must have one hash label (except spam entry). Labels that begin with `#` defines issue/PR type:
+
+| Label           | for Issue                                                                                                               | for PR                                                                                                                                            |
+| --------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `#bug`          | Bug report                                                                                                              | Bug fix                                                                                                                           |
+| `#code-quality` | Describe problem with code, architecture or productivity                                                                | Refactor, tests, tooling                                                                                                          |
+| `#feature`      | New feature request                                                                                                     | New feature implementation                                                                                                        |
+| `#refine`       | Propose improvement such as adjusting padding or refining UI style, excluding new features, bug fixes, and refactoring. | Implementation of improvement such as adjusting padding or refining UI style, excluding new features, bug fixes, and refactoring. |
+| `#doc`          | Documentation                                                                                                           | Documentation                                                                                                                     |
+| `#question`     | Troubleshooting: Installation, Running locally, Ask how to do something. Can be changed to `#bug` later.                | N/A                                                                                                                               |
+| `#SIP`          | Superset Improvement Proposal                                                                                           | N/A                                                                                                                               |
+| `#ASF`          | Tasks related to Apache Software Foundation policy                                                                      | Tasks related to Apache Software Foundation policy                                                                                |
+
+Then add other types of labels as appropriate.
+
+- **Descriptive labels (a.k.a. dot labels):** These labels that begin with `.` describe the details of the issue/PR, such as `.ui`, `.js`, `.install`, `.backend`, etc. Each issue/PR can have zero or more dot labels.
+- **Need labels:** These labels have pattern `need:xxx`, which describe the work required to progress, such as `need:rebase`, `need:update`, `need:screenshot`.
+- **Risk labels:** These labels have pattern `risk:xxx`, which describe the potential risk on adopting the work, such as `risk:db-migration`. The intention was to better understand the impact and create awareness for PRs that need more rigorous testing.
+- **Status labels:** These labels describe the status (`abandoned`, `wontfix`, `cant-reproduce`, etc.) Issue/PRs that are rejected or closed without completion should have one or more status labels.
+- **Version labels:** These have the pattern `vx.x` such as `v0.28`. Version labels on issues describe the version the bug was reported on. Version labels on PR describe the first release that will include the PR.
+
+Committers may also update title to reflect the issue/PR content if the author-provided title is not descriptive enough.
+
+If the PR passes CI tests and does not have any `need:` labels, it is ready for review, add label `review` and/or `design-review`.
+
+If an issue/PR has been inactive for >=30 days, it will be closed. If it does not have any status label, add `inactive`.
+
+When creating a PR, if you're aiming to have it included in a specific release, please tag it with the version label. For example, to have a PR considered for inclusion in Superset 1.1 use the label `v1.1`.
+
+## Revert Guidelines
+
+Reverting changes that are causing issues in the master branch is a normal and expected part of the development process. In an open source community, the ramifications of a change cannot always be fully understood. With that in mind, here are some considerations to keep in mind when considering a revert:
+
+- **Availability of the PR author:** If the original PR author or the engineer who merged the code is highly available and can provide a fix in a reasonable time frame, this would counter-indicate reverting.
+- **Severity of the issue:** How severe is the problem on master? Is it keeping the project from moving forward? Is there user impact? What percentage of users will experience a problem?
+- **Size of the change being reverted:** Reverting a single small PR is a much lower-risk proposition than reverting a massive, multi-PR change.
+- **Age of the change being reverted:** Reverting a recently-merged PR will be more acceptable than reverting an older PR. A bug discovered in an older PR is unlikely to be causing widespread serious issues.
+- **Risk inherent in reverting:** Will the reversion break critical functionality? Is the medicine more dangerous than the disease?
+- **Difficulty of crafting a fix:** In the case of issues with a clear solution, it may be preferable to implement and merge a fix rather than a revert.
+
+Should you decide that reverting is desirable, it is the responsibility of the Contributor performing the revert to:
+
+- **Contact the interested parties:** The PR's author and the engineer who merged the work should both be contacted and informed of the revert.
+- **Provide concise reproduction steps:** Ensure that the issue can be clearly understood and duplicated by the original author of the PR.
+- **Put the revert through code review:** The revert must be approved by another committer.
+
+## Design Guidelines
+
+### Capitalization guidelines
+
+#### Sentence case
+
+Use sentence-case capitalization for everything in the UI (except these \*\*).
+
+Sentence case is predominantly lowercase. Capitalize only the initial character of the first word, and other words that require capitalization, like:
+
+- **Proper nouns.** Objects in the product _are not_ considered proper nouns e.g. dashboards, charts, saved queries etc. Proprietary feature names eg. SQL Lab, Preset Manager _are_ considered proper nouns
+- **Acronyms** (e.g. CSS, HTML)
+- When referring to **UI labels that are themselves capitalized** from sentence case (e.g. page titles - Dashboards page, Charts page, Saved queries page, etc.)
+- User input that is reflected in the UI. E.g. a user-named a dashboard tab
+
+**Sentence case vs. Title case:**
+Title case: "A Dog Takes a Walk in Paris"
+Sentence case: "A dog takes a walk in Paris"
+
+**Why sentence case?**
+
+- It’s generally accepted as the quickest to read
+- It’s the easiest form to distinguish between common and proper nouns
+
+#### How to refer to UI elements
+
+When writing about a UI element, use the same capitalization as used in the UI.
+
+For example, if an input field is labeled “Name” then you refer to this as the “Name input field”. Similarly, if a button has the label “Save” in it, then it is correct to refer to the “Save button”.
+
+Where a product page is titled “Settings”, you refer to this in writing as follows:
+“Edit your personal information on the Settings page”.
+
+Often a product page will have the same title as the objects it contains. In this case, refer to the page as it appears in the UI, and the objects as common nouns:
+
+- Upload a dashboard on the Dashboards page
+- Go to Dashboards
+- View dashboard
+- View all dashboards
+- Upload CSS templates on the CSS templates page
+- Queries that you save will appear on the Saved queries page
+- Create custom queries in SQL Lab then create dashboards
+
+#### \*\*Exceptions to sentence case
+
+- Input labels, buttons and UI tabs are all caps
+- User input values (e.g. column names, SQL Lab tab names) should be in their original case
+
+## Programming Language Conventions
+
+### Python
+
+Parameters in the `config.py` (which are accessible via the Flask app.config dictionary) are
+assumed to always be defined and thus should be accessed directly via,
+
+```python
+blueprints = app.config["BLUEPRINTS"]
+```
+
+rather than,
+
+```python
+blueprints = app.config.get("BLUEPRINTS")
+```
+
+or similar as the later will cause typing issues. The former is of type `List[Callable]`
+whereas the later is of type `Optional[List[Callable]]`.
+
+#### Typing / Types Hints
+
+To ensure clarity, consistency, all readability, _all_ new functions should use
+[type hints](https://docs.python.org/3/library/typing.html) and include a
+docstring.
+
+Note per [PEP-484](https://www.python.org/dev/peps/pep-0484/#exceptions) no
+syntax for listing explicitly raised exceptions is proposed and thus the
+recommendation is to put this information in a docstring, i.e.,
+
+```python
+import math
+from typing import Union
+
+
+def sqrt(x: Union[float, int]) -> Union[float, int]:
+    """
+    Return the square root of x.
+
+    :param x: A number
+    :returns: The square root of the given number
+    :raises ValueError: If the number is negative
+    """
+
+    return math.sqrt(x)
+```
+
+### TypeScript
+
+TypeScript is fully supported and is the recommended language for writing all new frontend
+components. When modifying existing functions/components, migrating to TypeScript is
+appreciated, but not required. Examples of migrating functions/components to TypeScript can be
+found in [#9162](https://github.com/apache/superset/pull/9162) and [#9180](https://github.com/apache/superset/pull/9180).

docs/versioned_docs/version-6.0.0/contributing/howtos.mdx

@@ -0,0 +1,634 @@
+---
+title: Development How-tos
+hide_title: true
+sidebar_position: 4
+version: 1
+---
+# Development How-tos
+
+## Contributing to Documentation
+
+The latest documentation and tutorial are available at https://superset.apache.org/.
+
+The documentation site is built using [Docusaurus 3](https://docusaurus.io/), a modern
+static website generator, the source for which resides in `./docs`.
+
+### Local Development
+
+To set up a local development environment with hot reloading for the documentation site:
+
+```shell
+cd docs
+yarn install  # Installs NPM dependencies
+yarn start  # Starts development server at http://localhost:3000
+```
+
+### Build
+
+To create and serve a production build of the documentation site:
+
+```shell
+yarn build
+yarn serve
+```
+
+### Deployment
+
+Commits to `master` trigger a rebuild and redeploy of the documentation site. Submit pull requests that modify the documentation with the `docs:` prefix.
+
+## Creating Visualization Plugins
+
+Visualizations in Superset are implemented in JavaScript or TypeScript. Superset
+comes preinstalled with several visualizations types (hereafter "viz plugins") that
+can be found under the `superset-frontend/plugins` directory. Viz plugins are added to
+the application in the `superset-frontend/src/visualizations/presets/MainPreset.js`.
+The Superset project is always happy to review proposals for new high quality viz
+plugins. However, for highly custom viz types it is recommended to maintain a fork
+of Superset, and add the custom built viz plugins by hand.
+
+**Note:** Additional community-generated resources about creating and deploying custom visualization plugins can be found on the [Superset Wiki](https://github.com/apache/superset/wiki/Community-Resource-Library#creating-custom-data-visualizations)
+
+### Prerequisites
+
+In order to create a new viz plugin, you need the following:
+
+- Run MacOS or Linux (Windows is not officially supported, but may work)
+- Node.js 16
+- npm 7 or 8
+
+A general familiarity with [React](https://reactjs.org/) and the npm/Node system is
+also recommended.
+
+### Creating a simple Hello World viz plugin
+
+To get started, you need the Superset Yeoman Generator. It is recommended to use the
+version of the template that ships with the version of Superset you are using. This
+can be installed by doing the following:
+
+```bash
+npm i -g yo
+cd superset-frontend/packages/generator-superset
+npm i
+npm link
+```
+
+After this you can proceed to create your viz plugin. Create a new directory for your
+viz plugin with the prefix `superset-plugin-chart` and run the Yeoman generator:
+
+```bash
+mkdir /tmp/superset-plugin-chart-hello-world
+cd /tmp/superset-plugin-chart-hello-world
+```
+
+Initialize the viz plugin:
+
+```bash
+yo @superset-ui/superset
+```
+
+After that the generator will ask a few questions (the defaults should be fine):
+
+```bash
+$ yo @superset-ui/superset
+     _-----_     ╭──────────────────────────╮
+    |       |    │      Welcome to the      │
+    |--(o)--|    │    generator-superset    │
+   `---------´   │        generator!        │
+    ( _´U`_ )    ╰──────────────────────────╯
+    /___A___\   /
+     |  ~  |
+   __'.___.'__
+ ´   `  |° ´ Y `
+? Package name: superset-plugin-chart-hello-world
+? Description: Hello World
+? What type of chart would you like? Time-series chart
+   create package.json
+   create .gitignore
+   create babel.config.js
+   create jest.config.js
+   create README.md
+   create tsconfig.json
+   create src/index.ts
+   create src/plugin/buildQuery.ts
+   create src/plugin/controlPanel.ts
+   create src/plugin/index.ts
+   create src/plugin/transformProps.ts
+   create src/types.ts
+   create src/SupersetPluginChartHelloWorld.tsx
+   create test/index.test.ts
+   create test/__mocks__/mockExportString.js
+   create test/plugin/buildQuery.test.ts
+   create test/plugin/transformProps.test.ts
+   create types/external.d.ts
+   create src/images/thumbnail.png
+```
+
+To build the viz plugin, run the following commands:
+
+```bash
+npm i --force
+npm run build
+```
+
+Alternatively, to run the viz plugin in development mode (=rebuilding whenever changes
+are made), start the dev server with the following command:
+
+```bash
+npm run dev
+```
+
+To add the package to Superset, go to the `superset-frontend` subdirectory in your
+Superset source folder run
+
+```bash
+npm i -S /tmp/superset-plugin-chart-hello-world
+```
+
+If you publish your package to npm, you can naturally install directly from there, too.
+After this edit the `superset-frontend/src/visualizations/presets/MainPreset.js`
+and make the following changes:
+
+```js
+import { SupersetPluginChartHelloWorld } from 'superset-plugin-chart-hello-world';
+```
+
+to import the viz plugin and later add the following to the array that's passed to the
+`plugins` property:
+
+```js
+new SupersetPluginChartHelloWorld().configure({ key: 'ext-hello-world' }),
+```
+
+After that the viz plugin should show up when you run Superset, e.g. the development
+server:
+
+```bash
+npm run dev-server
+```
+
+## Testing
+
+### Python Testing
+
+`pytest`, backend by docker-compose is how we recommend running tests locally.
+
+For a more complex test matrix (against different database backends, python versions, ...) you
+can rely on our GitHub Actions by simply opening a draft pull request.
+
+Note that the test environment uses a temporary directory for defining the
+SQLite databases which will be cleared each time before the group of test
+commands are invoked.
+
+There is also a utility script included in the Superset codebase to run python integration tests. The [readme can be
+found here](https://github.com/apache/superset/tree/master/scripts/tests)
+
+To run all integration tests for example, run this script from the root directory:
+
+```bash
+scripts/tests/run.sh
+```
+
+You can run unit tests found in './tests/unit_tests' for example with pytest. It is a simple way to run an isolated test that doesn't need any database setup
+
+```bash
+pytest ./link_to_test.py
+```
+
+#### Testing with local Presto connections
+
+If you happen to change db engine spec for Presto/Trino, you can run a local Presto cluster with Docker:
+
+```bash
+docker run -p 15433:15433 starburstdata/presto:350-e.6
+```
+
+Then update `SUPERSET__SQLALCHEMY_EXAMPLES_URI` to point to local Presto cluster:
+
+```bash
+export SUPERSET__SQLALCHEMY_EXAMPLES_URI=presto://localhost:15433/memory/default
+```
+
+### Frontend Testing
+
+We use [Jest](https://jestjs.io/) and [Enzyme](https://airbnb.io/enzyme/) to test TypeScript/JavaScript. Tests can be run with:
+
+```bash
+cd superset-frontend
+npm run test
+```
+
+To run a single test file:
+
+```bash
+npm run test -- path/to/file.js
+```
+
+### E2E Integration Testing
+
+For E2E testing, we recommend that you use a `docker compose` backend
+
+```bash
+CYPRESS_CONFIG=true docker compose up --build
+```
+`docker compose` will get to work and expose a Cypress-ready Superset app.
+This app uses a different database schema (`superset_cypress`) to keep it isolated from
+your other dev environmen(s)t, a specific set of examples, and a set of configurations that
+aligns with the expectations within the end-to-end tests.  Also note that it's served on a
+different port than the default port for the backend (`8088`).
+
+Now in another terminal, let's get ready to execute some Cypress commands. First, tell cypress
+to connect to the Cypress-ready Superset backend.
+
+```
+CYPRESS_BASE_URL=http://localhost:8081
+```
+
+```bash
+# superset-frontend/cypress-base is the base folder for everything Cypress-related
+# It's essentially its own npm app, with its own dependencies, configurations and utilities
+cd superset-frontend/cypress-base
+npm install
+
+# use interactive mode to run tests, while keeping memory usage contained
+# this will fire up an interactive Cypress UI
+# as you alter the code, the tests will re-run automatically, and you can visualize each
+# and every step for debugging purposes
+npx cypress open --config numTestsKeptInMemory=5
+
+# to run the test suite on the command line using chrome (same as CI)
+npm run cypress-run-chrome
+
+# run tests from a specific file
+npm run cypress-run-chrome -- --spec cypress/e2e/explore/link.test.ts
+
+# run specific file with video capture
+npm run cypress-run-chrome -- --spec cypress/e2e/dashboard/index.test.js --config video=true
+
+# to open the cypress ui
+npm run cypress-debug
+
+```
+
+See [`superset-frontend/cypress_build.sh`](https://github.com/apache/superset/blob/master/superset-frontend/cypress_build.sh).
+
+As an alternative you can use docker compose environment for testing:
+
+Make sure you have added below line to your /etc/hosts file:
+`127.0.0.1 db`
+
+If you already have launched Docker environment please use the following command to assure a fresh database instance:
+`docker compose down -v`
+
+Launch environment:
+
+`CYPRESS_CONFIG=true docker compose up`
+
+It will serve backend and frontend on port 8088.
+
+Run Cypress tests:
+
+```bash
+cd cypress-base
+npm install
+npm run cypress open
+```
+
+### Debugging Server App
+
+Follow these instructions to debug the Flask app running inside a docker container.
+
+First add the following to the ./docker-compose.yaml file
+
+```diff
+superset:
+    env_file: docker/.env
+    image: *superset-image
+    container_name: superset_app
+    command: ["/app/docker/docker-bootstrap.sh", "app"]
+    restart: unless-stopped
++   cap_add:
++     - SYS_PTRACE
+    ports:
+      - 8088:8088
++     - 5678:5678
+    user: "root"
+    depends_on: *superset-depends-on
+    volumes: *superset-volumes
+    environment:
+      CYPRESS_CONFIG: "${CYPRESS_CONFIG}"
+```
+
+Start Superset as usual
+
+```bash
+docker compose up
+```
+
+Install the required libraries and packages to the docker container
+
+Enter the superset_app container
+
+```bash
+docker exec -it superset_app /bin/bash
+root@39ce8cf9d6ab:/app#
+```
+
+Run the following commands inside the container
+
+```bash
+apt update
+apt install -y gdb
+apt install -y net-tools
+pip install debugpy
+```
+
+Find the PID for the Flask process. Make sure to use the first PID. The Flask app will re-spawn a sub-process every time you change any of the python code. So it's important to use the first PID.
+
+```bash
+ps -ef
+
+UID        PID  PPID  C STIME TTY          TIME CMD
+root         1     0  0 14:09 ?        00:00:00 bash /app/docker/docker-bootstrap.sh app
+root         6     1  4 14:09 ?        00:00:04 /usr/local/bin/python /usr/bin/flask run -p 8088 --with-threads --reload --debugger --host=0.0.0.0
+root        10     6  7 14:09 ?        00:00:07 /usr/local/bin/python /usr/bin/flask run -p 8088 --with-threads --reload --debugger --host=0.0.0.0
+```
+
+Inject debugpy into the running Flask process. In this case PID 6.
+
+```bash
+python3 -m debugpy --listen 0.0.0.0:5678 --pid 6
+```
+
+Verify that debugpy is listening on port 5678
+
+```bash
+netstat -tunap
+
+Active Internet connections (servers and established)
+Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
+tcp        0      0 0.0.0.0:5678            0.0.0.0:*               LISTEN      462/python
+tcp        0      0 0.0.0.0:8088            0.0.0.0:*               LISTEN      6/python
+```
+
+You are now ready to attach a debugger to the process. Using VSCode you can configure a launch configuration file .vscode/launch.json like so.
+
+```json
+{
+    "version": "0.2.0",
+    "configurations": [
+        {
+            "name": "Attach to Superset App in Docker Container",
+            "type": "python",
+            "request": "attach",
+            "connect": {
+                "host": "127.0.0.1",
+                "port": 5678
+            },
+            "pathMappings": [
+                {
+                    "localRoot": "${workspaceFolder}",
+                    "remoteRoot": "/app"
+                }
+            ]
+        },
+    ]
+}
+```
+
+VSCode will not stop on breakpoints right away. We've attached to PID 6 however it does not yet know of any sub-processes. In order to "wakeup" the debugger you need to modify a python file. This will trigger Flask to reload the code and create a new sub-process. This new sub-process will be detected by VSCode and breakpoints will be activated.
+
+### Debugging Server App in Kubernetes Environment
+
+To debug Flask running in POD inside a kubernetes cluster, you'll need to make sure the pod runs as root and is granted the `SYS_TRACE` capability. These settings should not be used in production environments.
+
+```yaml
+  securityContext:
+    capabilities:
+      add: ["SYS_PTRACE"]
+```
+
+See [set capabilities for a container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) for more details.
+
+Once the pod is running as root and has the `SYS_PTRACE` capability it will be able to debug the Flask app.
+
+You can follow the same instructions as in `docker compose`. Enter the pod and install the required library and packages: gdb, netstat and debugpy.
+
+Often in a Kubernetes environment nodes are not addressable from outside the cluster. VSCode will thus be unable to remotely connect to port 5678 on a Kubernetes node. In order to do this you need to create a tunnel that port forwards 5678 to your local machine.
+
+```bash
+kubectl port-forward  pod/superset-<some random id> 5678:5678
+```
+
+You can now launch your VSCode debugger with the same config as above. VSCode will connect to to 127.0.0.1:5678 which is forwarded by kubectl to your remote kubernetes POD.
+
+### Storybook
+
+Superset includes a [Storybook](https://storybook.js.org/) to preview the layout/styling of various Superset components, and variations thereof. To open and view the Storybook:
+
+```bash
+cd superset-frontend
+npm run storybook
+```
+
+When contributing new React components to Superset, please try to add a Story alongside the component's `jsx/tsx` file.
+
+## Contributing Translations
+
+We use [Flask-Babel](https://python-babel.github.io/flask-babel/) to translate Superset.
+In Python files, we use the following
+[translation functions](https://python-babel.github.io/flask-babel/#using-translations)
+from `Flask-Babel`:
+
+- `gettext` and `lazy_gettext` (usually aliased to `_`): for translating singular
+  strings.
+- `ngettext`: for translating strings that might become plural.
+
+```python
+from flask_babel import lazy_gettext as _
+```
+
+then wrap the translatable strings with it, e.g. `_('Translate me')`.
+During extraction, string literals passed to `_` will be added to the
+generated `.po` file for each language for later translation.
+
+At runtime, the `_` function will return the translation of the given
+string for the current language, or the given string itself
+if no translation is available.
+
+In TypeScript/JavaScript, the technique is similar:
+we import `t` (simple translation), `tn` (translation containing a number).
+
+```javascript
+import { t, tn } from "@superset-ui/translation";
+```
+
+### Enabling language selection
+
+Add the `LANGUAGES` variable to your `superset_config.py`. Having more than one
+option inside will add a language selection dropdown to the UI on the right side
+of the navigation bar.
+
+```python
+LANGUAGES = {
+    'en': {'flag': 'us', 'name': 'English'},
+    'fr': {'flag': 'fr', 'name': 'French'},
+    'zh': {'flag': 'cn', 'name': 'Chinese'},
+}
+```
+
+### Creating a new language dictionary
+
+First check if the language code for your target language already exists. Check if the
+[two letter ISO 639-1 code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes)
+for your target language already exists in the `superset/translations` directory:
+
+```bash
+ls superset/translations | grep -E "^[a-z]{2}\/"
+```
+
+If your language already has a preexisting translation, skip to the next section
+
+The following languages are already supported by Flask AppBuilder, and will make it
+easier to translate the application to your target language:
+[Flask AppBuilder i18n documentation](https://flask-appbuilder.readthedocs.io/en/latest/i18n.html)
+
+To create a dictionary for a new language, first make sure the necessary dependencies are installed:
+
+```bash
+pip install -r superset/translations/requirements.txt
+```
+
+Then run the following, where `LANGUAGE_CODE` is replaced with the language code for your target
+language:
+
+```bash
+pybabel init -i superset/translations/messages.pot -d superset/translations -l LANGUAGE_CODE
+```
+
+For instance, to add a translation for Finnish (language code `fi`), run the following:
+
+```bash
+pybabel init -i superset/translations/messages.pot -d superset/translations -l fi
+```
+
+### Extracting new strings for translation
+
+Periodically, when working on translations, we need to extract the strings from both the
+backend and the frontend to compile a list of all strings to be translated. It doesn't
+happen automatically and is a required step to gather the strings and get them into the
+`.po` files where they can be translated, so that they can then be compiled.
+
+This script does just that:
+
+```bash
+./scripts/translations/babel_update.sh
+```
+
+### Updating language files
+
+Run the following command to update the language files with the new extracted strings.
+
+```bash
+ pybabel update -i superset/translations/messages.pot -d superset/translations --ignore-obsolete
+```
+
+You can then translate the strings gathered in files located under
+`superset/translation`, where there's one folder per language. You can use [Poedit](https://poedit.net/features)
+to translate the `po` file more conveniently.
+Here is [a tutorial](https://web.archive.org/web/20220517065036/https://wiki.lxde.org/en/Translate_*.po_files_with_Poedit).
+
+To perform the translation on MacOS, you can install `poedit` via Homebrew:
+
+```bash
+brew install poedit
+```
+
+After this, just start the `poedit` application and open the `messages.po` file. In the
+case of the Finnish translation, this would be `superset/translations/fi/LC_MESSAGES/messages.po`.
+
+### Applying translations
+
+To make the translations available on the frontend, we need to convert the PO file into
+a collection of JSON files. To convert all PO files to formatted JSON files you can use
+the `build-translation` script
+
+```bash
+# Install dependencies if you haven't already
+cd superset-frontend/ && npm ci
+# Compile translations for the frontend
+npm run build-translation
+```
+
+Finally, for the translations to take effect we need to compile translation catalogs into
+binary MO files for the backend using `pybabel`.
+
+```bash
+# inside the project root
+pybabel compile -d superset/translations
+```
+
+## Linting
+
+### Python
+
+We use [ruff](https://github.com/astral-sh/ruff) for linting which can be invoked via:
+
+```
+# auto-reformat using ruff
+ruff format
+
+# lint check with ruff
+ruff check
+
+# lint fix with ruff
+ruff check --fix
+```
+
+Ruff configuration is located in our
+(pyproject.toml)[https://github.com/apache/superset/blob/master/pyproject.toml] file
+
+All this is configured to run in pre-commit hooks, which we encourage you to setup
+with `pre-commit install`
+
+### TypeScript
+
+```bash
+cd superset-frontend
+npm ci
+# run eslint checks
+npm run eslint -- .
+# run tsc (typescript) checks
+npm run type
+```
+
+If using the eslint extension with vscode, put the following in your workspace `settings.json` file:
+
+```json
+"eslint.workingDirectories": [
+  "superset-frontend"
+]
+```
+
+## GitHub Ephemeral Environments
+
+On any given pull request on GitHub, it's possible to create a temporary environment/deployment
+by simply adding the label `testenv-up` to the PR.  Once you add the `testenv-up` label, a
+GitHub Action will be triggered that will:
+
+- build a docker image
+- deploy it in EC2 (sponsored by the folks at [Preset](https://preset.io))
+- write a comment on the PR with a link to the ephemeral environment
+
+For more advanced use cases, it's possible to set a feature flag on the PR body, which will
+take effect on the ephemeral environment. For example, if you want to set the `TAGGING_SYSTEM`
+feature flag to `true`, you can add the following line to the PR body/description:
+
+```
+FEATURE_TAGGING_SYSTEM=true
+```
+
+Simarly, it's possible to disable feature flags with:
+
+```
+FEATURE_TAGGING_SYSTEM=false
+```

docs/versioned_docs/version-6.0.0/contributing/misc.mdx

@@ -0,0 +1,55 @@
+---
+sidebar_position: 6
+version: 1
+---
+
+# Miscellaneous
+
+## Reporting a Security Vulnerability
+
+Please report security vulnerabilities to private@superset.apache.org.
+
+In the event a community member discovers a security flaw in Superset, it is important to follow the [Apache Security Guidelines](https://www.apache.org/security/committers.html) and release a fix as quickly as possible before public disclosure. Reporting security vulnerabilities through the usual GitHub Issues channel is not ideal as it will publicize the flaw before a fix can be applied.
+
+## SQL Lab Async
+
+It's possible to configure a local database to operate in `async` mode,
+to work on `async` related features.
+
+To do this, you'll need to:
+
+- Add an additional database entry. We recommend you copy the connection
+  string from the database labeled `main`, and then enable `SQL Lab` and the
+  features you want to use. Don't forget to check the `Async` box
+- Configure a results backend, here's a local `FileSystemCache` example,
+  not recommended for production,
+  but perfect for testing (stores cache in `/tmp`)
+
+  ```python
+  from flask_caching.backends.filesystemcache import FileSystemCache
+  RESULTS_BACKEND = FileSystemCache('/tmp/sqllab')
+  ```
+
+- Start up a celery worker
+
+  ```shell script
+  celery --app=superset.tasks.celery_app:app worker -O fair
+  ```
+
+Note that:
+
+- for changes that affect the worker logic, you'll have to
+  restart the `celery worker` process for the changes to be reflected.
+- The message queue used is a `sqlite` database using the `SQLAlchemy`
+  experimental broker. Ok for testing, but not recommended in production
+- In some cases, you may want to create a context that is more aligned
+  to your production environment, and use the similar broker as well as
+  results backend configuration
+
+## Async Chart Queries
+
+It's possible to configure database queries for charts to operate in `async` mode. This is especially useful for dashboards with many charts that may otherwise be affected by browser connection limits. To enable async queries for dashboards and Explore, the following dependencies are required:
+
+- Redis 5.0+ (the feature utilizes [Redis Streams](https://redis.io/topics/streams-intro))
+- Cache backends enabled via the `CACHE_CONFIG` and `DATA_CACHE_CONFIG` config settings
+- Celery workers configured and running to process async tasks

docs/versioned_docs/version-6.0.0/contributing/resources.mdx

@@ -0,0 +1,104 @@
+---
+sidebar_position: 5
+version: 1
+---
+
+import InteractiveSVG from '../../../src/components/InteractiveERDSVG';
+import Mermaid from '@theme/Mermaid';
+
+# Resources
+
+## High Level Architecture
+<div style={{ maxWidth: "600px", margin: "0 auto",  marginLeft: 0, marginRight: "auto" }}>
+```mermaid
+flowchart TD
+
+  %% Top Level
+  LB["<b>Load Balancer(s)</b><br/>(optional)"]
+  LB -.-> WebServers
+
+  %% Web Servers
+  subgraph WebServers ["<b>Web Server(s)</b>"]
+    WS1["<b>Frontend</b><br/>(React, AntD, ECharts, AGGrid)"]
+    WS2["<b>Backend</b><br/>(Python, Flask, SQLAlchemy, Pandas, ...)"]
+  end
+
+  %% Infra
+  subgraph InfraServices ["<b>Infra</b>"]
+    DB[("<b>Metadata Database</b><br/>(Postgres / MySQL)")]
+
+    subgraph Caching ["<b>Caching Subservices<br/></b>(Redis, memcache, S3, ...)"]
+      direction LR
+      DummySpace[" "]:::invisible
+      QueryCache["<b>Query Results Cache</b><br/>(Accelerated Dashboards)"]
+      CsvCache["<b>CSV Exports Cache</b>"]
+      ThumbnailCache["<b>Thumbnails Cache</b>"]
+      AlertImageCache["<b>Alert/Report Images Cache</b>"]
+	  QueryCache -- " " --> CsvCache
+	  linkStyle 1 stroke:transparent;
+      ThumbnailCache -- " " --> AlertImageCache
+	  linkStyle 2 stroke:transparent;
+    end
+
+    Broker(("<b>Message Queue</b><br/>(Redis / RabbitMQ / SQS)"))
+  end
+
+  AsyncBackend["<b>Async Workers (Celery)</b><br>required for Alerts & Reports, thumbnails, CSV exports, long-running workloads, ..."]
+
+  %% External DBs
+  subgraph ExternalDatabases ["<b>Analytics Databases</b>"]
+    direction LR
+    BigQuery[(BigQuery)]
+    Snowflake[(Snowflake)]
+    Redshift[(Redshift)]
+    Postgres[(Postgres)]
+    Postgres[(... any ...)]
+  end
+
+  %% Connections
+  LB -.-> WebServers
+  WebServers --> DB
+  WebServers -.-> Caching
+  WebServers -.-> Broker
+  WebServers -.-> ExternalDatabases
+
+  Broker -.-> AsyncBackend
+
+  AsyncBackend -.-> ExternalDatabases
+  AsyncBackend -.-> Caching
+
+
+
+  %% Legend styling
+  classDef requiredNode stroke-width:2px,stroke:black;
+  class Required requiredNode;
+  class Optional optionalNode;
+
+  %% Hide real arrow
+  linkStyle 0 stroke:transparent;
+
+  %% Styling
+  classDef optionalNode stroke-dasharray: 5 5, opacity:0.9;
+  class LB optionalNode;
+  class Caching optionalNode;
+  class AsyncBackend optionalNode;
+  class Broker optionalNode;
+  class QueryCache optionalNode;
+  class CsvCache optionalNode;
+  class ThumbnailCache optionalNode;
+  class AlertImageCache optionalNode;
+  class Celery optionalNode;
+
+  classDef invisible fill:transparent,stroke:transparent;
+```
+</div>
+
+## Entity-Relationship Diagram
+
+Here is our interactive ERD:
+
+<InteractiveSVG />
+
+<br />
+
+[Download the .svg](https://github.com/apache/superset/tree/master/docs/static/img/erd.svg)

docs/versioned_docs/version-6.0.0/faq.mdx

@@ -0,0 +1,285 @@
+---
+sidebar_position: 9
+---
+
+# FAQ
+
+## How big of a dataset can Superset handle?
+
+Superset can work with even gigantic databases! Superset acts as a thin layer above your underlying
+databases or data engines, which do all the processing.  Superset simply visualizes the results of
+the query.
+
+The key to achieving acceptable performance in Superset is whether your database can execute queries
+and return results at a speed that is acceptable to your users. If you experience slow performance with
+Superset, benchmark and tune your data warehouse.
+
+## What are the computing specifications required to run Superset?
+
+The specs of your Superset installation depend on how many users you have and what their activity is, not
+on the size of your data.  Superset admins in the community have reported 8GB RAM, 2vCPUs as adequate to
+run a moderately-sized instance. To develop Superset, e.g., compile code or build images, you may
+need more power.
+
+Monitor your resource usage and increase or decrease as needed. Note that Superset usage has a tendency
+to occur in spikes, e.g., if everyone in a meeting loads the same dashboard at once.
+
+Superset's application metadata does not require a very large database to store it, though
+the log file grows over time.
+
+## Can I join / query multiple tables at one time?
+
+Not in the Explore or Visualization UI. A Superset SQLAlchemy datasource can only be a single table
+or a view.
+
+When working with tables, the solution would be to create a table that contains all the fields
+needed for your analysis, most likely through some scheduled batch process.
+
+A view is a simple logical layer that abstracts an arbitrary SQL queries as a virtual table. This can
+allow you to join and union multiple tables and to apply some transformation using arbitrary SQL
+expressions. The limitation there is your database performance, as Superset effectively will run a
+query on top of your query (view). A good practice may be to limit yourself to joining your main
+large table to one or many small tables only, and avoid using _GROUP BY_ where possible as Superset
+will do its own _GROUP BY_ and doing the work twice might slow down performance.
+
+Whether you use a table or a view, performance depends on how fast your database can deliver
+the result to users interacting with Superset.
+
+However, if you are using SQL Lab, there is no such limitation. You can write SQL queries to join
+multiple tables as long as your database account has access to the tables.
+
+## How do I create my own visualization?
+
+We recommend reading the instructions in
+[Creating Visualization Plugins](/docs/contributing/howtos#creating-visualization-plugins).
+
+## Can I upload and visualize CSV data?
+
+Absolutely! Read the instructions [here](/docs/using-superset/exploring-data) to learn
+how to enable and use CSV upload.
+
+## Why are my queries timing out?
+
+There are many possible causes for why a long-running query might time out.
+
+For running long query from Sql Lab, by default Superset allows it run as long as 6 hours before it
+being killed by celery. If you want to increase the time for running query, you can specify the
+timeout in configuration. For example:
+
+```python
+SQLLAB_ASYNC_TIME_LIMIT_SEC = 60 * 60 * 6
+```
+
+If you are seeing timeouts (504 Gateway Time-out) when loading dashboard or explore slice, you are
+probably behind gateway or proxy server (such as Nginx). If it did not receive a timely response
+from Superset server (which is processing long queries), these web servers will send 504 status code
+to clients directly. Superset has a client-side timeout limit to address this issue. If query didn’t
+come back within client-side timeout (60 seconds by default), Superset will display warning message
+to avoid gateway timeout message. If you have a longer gateway timeout limit, you can change the
+timeout settings in **superset_config.py**:
+
+```python
+SUPERSET_WEBSERVER_TIMEOUT = 60
+```
+
+## Why is the map not visible in the geospatial visualization?
+
+You need to register a free account at [Mapbox.com](https://www.mapbox.com), obtain an API key, and add it
+to **.env** at the key MAPBOX_API_KEY:
+
+```python
+MAPBOX_API_KEY = "longstringofalphanumer1c"
+```
+
+## How to limit the timed refresh on a dashboard?
+
+By default, the dashboard timed refresh feature allows you to automatically re-query every slice on
+a dashboard according to a set schedule. Sometimes, however, you won’t want all of the slices to be
+refreshed - especially if some data is slow moving, or run heavy queries. To exclude specific slices
+from the timed refresh process, add the `timed_refresh_immune_slices` key to the dashboard JSON
+Metadata field:
+
+```json
+{
+   "filter_immune_slices": [],
+    "expanded_slices": {},
+    "filter_immune_slice_fields": {},
+    "timed_refresh_immune_slices": [324]
+}
+```
+
+In the example above, if a timed refresh is set for the dashboard, then every slice except 324 will
+be automatically re-queried on schedule.
+
+Slice refresh will also be staggered over the specified period. You can turn off this staggering by
+setting the `stagger_refresh` to false and modify the stagger period by setting `stagger_time` to a
+value in milliseconds in the JSON Metadata field:
+
+```json
+{
+    "stagger_refresh": false,
+    "stagger_time": 2500
+}
+```
+
+Here, the entire dashboard will refresh at once if periodic refresh is on. The stagger time of 2.5
+seconds is ignored.
+
+**Why does ‘flask fab’ or superset freeze/hang/not responding when started (my home directory is
+NFS mounted)?**
+
+By default, Superset creates and uses an SQLite database at `~/.superset/superset.db`. SQLite is
+known to [not work well if used on NFS](https://www.sqlite.org/lockingv3.html) due to broken file
+locking implementation on NFS.
+
+You can override this path using the **SUPERSET_HOME** environment variable.
+
+Another workaround is to change where superset stores the sqlite database by adding the following in
+`superset_config.py`:
+
+```python
+SQLALCHEMY_DATABASE_URI = 'sqlite:////new/location/superset.db?check_same_thread=false'
+```
+
+You can read more about customizing Superset using the configuration file
+[here](/docs/configuration/configuring-superset).
+
+## What if the table schema changed?
+
+Table schemas evolve, and Superset needs to reflect that. It’s pretty common in the life cycle of a
+dashboard to want to add a new dimension or metric. To get Superset to discover your new columns,
+all you have to do is to go to **Data -> Datasets**, click the edit icon next to the dataset
+whose schema has changed, and hit **Sync columns from source** from the **Columns** tab.
+Behind the scene, the new columns will get merged. Following this, you may want to re-edit the
+table afterwards to configure the Columns tab, check the appropriate boxes and save again.
+
+## What database engine can I use as a backend for Superset?
+
+To clarify, the database backend is an OLTP database used by Superset to store its internal
+information like your list of users and dashboard definitions. While Superset supports a
+[variety of databases as data _sources_](/docs/configuration/databases#installing-database-drivers),
+only a few database engines are supported for use as the OLTP backend / metadata store.
+
+Superset is tested using MySQL, PostgreSQL, and SQLite backends. It’s recommended you install
+Superset on one of these database servers for production.  Installation on other OLTP databases
+may work but isn’t tested.  It has been reported that [Microsoft SQL Server does _not_
+work as a Superset backend](https://github.com/apache/superset/issues/18961). Column-store,
+non-OLTP databases are not designed for this type of workload.
+
+## How can I configure OAuth authentication and authorization?
+
+You can take a look at this Flask-AppBuilder
+[configuration example](https://github.com/dpgaspar/Flask-AppBuilder/blob/master/examples/oauth/config.py).
+
+## Is there a way to force the dashboard to use specific colors?
+
+It is possible on a per-dashboard basis by providing a mapping of labels to colors in the JSON
+Metadata attribute using the `label_colors` key. You can use either the full hex color, a named color,
+like `red`, `coral` or `lightblue`, or the index in the current color palette (0 for first color, 1 for
+second etc). Example:
+
+```json
+{
+    "label_colors": {
+        "foo": "#FF69B4",
+        "bar": "lightblue",
+        "baz": 0
+    }
+}
+```
+
+## Does Superset work with [insert database engine here]?
+
+The [Connecting to Databases section](/docs/configuration/databases) provides the best
+overview for supported databases. Database engines not listed on that page may work too. We rely on
+the community to contribute to this knowledge base.
+
+For a database engine to be supported in Superset through the SQLAlchemy connector, it requires
+having a Python compliant [SQLAlchemy dialect](https://docs.sqlalchemy.org/en/13/dialects/) as well
+as a [DBAPI driver](https://www.python.org/dev/peps/pep-0249/) defined. Database that have limited
+SQL support may work as well. For instance it’s possible to connect to Druid through the SQLAlchemy
+connector even though Druid does not support joins and subqueries. Another key element for a
+database to be supported is through the Superset Database Engine Specification interface. This
+interface allows for defining database-specific configurations and logic that go beyond the
+SQLAlchemy and DBAPI scope. This includes features like:
+
+- date-related SQL function that allow Superset to fetch different time granularities when running
+  time-series queries
+- whether the engine supports subqueries. If false, Superset may run 2-phase queries to compensate
+  for the limitation
+- methods around processing logs and inferring the percentage of completion of a query
+- technicalities as to how to handle cursors and connections if the driver is not standard DBAPI
+
+Beyond the SQLAlchemy connector, it’s also possible, though much more involved, to extend Superset
+and write your own connector. The only example of this at the moment is the Druid connector, which
+is getting superseded by Druid’s growing SQL support and the recent availability of a DBAPI and
+SQLAlchemy driver. If the database you are considering integrating has any kind of SQL support,
+it’s probably preferable to go the SQLAlchemy route. Note that for a native connector to be possible
+the database needs to have support for running OLAP-type queries and should be able to do things that
+are typical in basic SQL:
+
+- aggregate data
+- apply filters
+- apply HAVING-type filters
+- be schema-aware, expose columns and types
+
+## Does Superset offer a public API?
+
+Yes, a public REST API, and the surface of that API formal is expanding steadily. You can read more about this API and
+interact with it using Swagger [here](/docs/api).
+
+Some of the
+original vision for the collection of endpoints under **/api/v1** was originally specified in
+[SIP-17](https://github.com/apache/superset/issues/7259) and constant progress has been
+made to cover more and more use cases.
+
+The API available is documented using [Swagger](https://swagger.io/) and the documentation can be
+made available under **/swagger/v1** by enabling the following flag in `superset_config.py`:
+
+```python
+FAB_API_SWAGGER_UI = True
+```
+
+There are other undocumented [private] ways to interact with Superset programmatically that offer no
+guarantees and are not recommended but may fit your use case temporarily:
+
+- using the ORM (SQLAlchemy) directly
+- using the internal FAB ModelView API (to be deprecated in Superset)
+- altering the source code in your fork
+
+## How can I see usage statistics (e.g., monthly active users)?
+
+This functionality is not included with Superset, but you can extract and analyze Superset's application
+metadata to see what actions have occurred.  By default, user activities are logged in the `logs` table
+in Superset's metadata database.  One company has published a write-up of [how they analyzed Superset
+usage, including example queries](https://engineering.hometogo.com/monitor-superset-usage-via-superset-c7f9fba79525).
+
+## What Does Hours Offset in the Edit Dataset view do?
+
+In the Edit Dataset view, you can specify a time offset. This field lets you configure the
+number of hours to be added or subtracted from the time column.
+This can be used, for example, to convert UTC time to local time.
+
+## Does Superset collect any telemetry data?
+
+Superset uses [Scarf](https://about.scarf.sh/) by default to collect basic telemetry data upon installing and/or running Superset. This data helps the maintainers of Superset better understand which versions of Superset are being used, in order to prioritize patch/minor releases and security fixes.
+We use the [Scarf Gateway](https://docs.scarf.sh/gateway/) to sit in front of container registries, the [scarf-js](https://about.scarf.sh/package-sdks) package to track `npm` installations, and a Scarf pixel to gather anonymous analytics on Superset page views.
+Scarf purges PII and provides aggregated statistics. Superset users can easily opt out of analytics in various ways documented [here](https://docs.scarf.sh/gateway/#do-not-track) and [here](https://docs.scarf.sh/package-analytics/#as-a-user-of-a-package-using-scarf-js-how-can-i-opt-out-of-analytics).
+Superset maintainers can also opt out of telemetry data collection by setting the `SCARF_ANALYTICS` environment variable to `false` in the Superset container (or anywhere Superset/webpack are run).
+Additional opt-out instructions for Docker users are available on the [Docker Installation](/docs/installation/docker-compose) page.
+
+## Does Superset have an archive panel or trash bin from which a user can recover deleted assets?
+
+No. Currently, there is no way to recover a deleted Superset dashboard/chart/dataset/database from the UI. However, there is an [ongoing discussion](https://github.com/apache/superset/discussions/18386) about implementing such a feature.
+
+Hence, it is recommended to take periodic backups of the metadata database. For recovery, you can launch a recovery instance of a Superset server with the backed-up copy of the DB attached and use the Export Dashboard button in the Superset UI (or the `superset export-dashboards` CLI command). Then, take the .zip file and import it into the current Superset instance.
+
+Alternatively, you can programmatically take regular exports of the assets as a backup.
+
+## I ran a security scan of the Superset container image and it showed dozens of "high" and "critical" vulnerabilities! Can you release a version of Superset without these?
+
+You are talking about dependency CVEs: identified vulnerabilities in software that Superset uses. Most of these CVEs are in the Linux kernel or Python, both of which have many other people working on their security.
+
+We address these dependency CVEs as best we can by regularly updating our dependencies to newer versions. We use bots to assist with that and cheerfully welcome pull requests from humans that fix dependency CVEs.
+
+The Superset [security team](https://superset.apache.org/docs/security/#reporting-security-vulnerabilities) focuses primarily on vulnerabilities _in Superset itself_. See our [CVEs page](https://superset.apache.org/docs/security/cves) for a list of past Superset CVEs.

docs/versioned_docs/version-6.0.0/installation/architecture.mdx

@@ -0,0 +1,72 @@
+---
+title: Architecture
+hide_title: true
+sidebar_position: 1
+version: 1
+---
+
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+# Architecture
+
+This page is meant to give new administrators an understanding of Superset's components.
+
+## Components
+
+A Superset installation is made up of these components:
+
+1. The Superset application itself
+2. A metadata database
+3. A caching layer (optional, but necessary for some features)
+4. A worker & beat (optional, but necessary for some features)
+
+### Optional components and associated features
+
+The optional components above are necessary to enable these features:
+
+- [Alerts and Reports](/docs/configuration/alerts-reports)
+- [Caching](/docs/configuration/cache)
+- [Async Queries](/docs/configuration/async-queries-celery/)
+- [Dashboard Thumbnails](/docs/configuration/cache/#caching-thumbnails)
+
+If you install with Kubernetes or Docker Compose, all of these components will be created.
+
+However, installing from PyPI only creates the application itself. Users installing from PyPI will need to configure a caching layer, worker, and beat on their own if they wish to enable the above features. Configuration of those components for a PyPI install is not currently covered in this documentation.
+
+Here are further details on each component.
+
+### The Superset Application
+
+This is the core application. Superset operates like this:
+
+- A user visits a chart or dashboard
+- That triggers a SQL query to the data warehouse holding the underlying dataset
+- The resulting data is served up in a data visualization
+- The Superset application is comprised of the Python (Flask) backend application (server), API layer, and the React frontend, built via Webpack, and static assets needed for the application to work
+
+### Metadata Database
+
+This is where chart and dashboard definitions, user information, logs, etc. are stored. Superset is tested to work with PostgreSQL and MySQL databases as the metadata database (not be confused with a data source like your data warehouse, which could be a much greater variety of options like Snowflake, Redshift, etc.).
+
+Some installation methods like our Quickstart and PyPI come configured by default to use a SQLite on-disk database. And in a Docker Compose installation, the data would be stored in a PostgreSQL container volume. Neither of these cases are recommended for production instances of Superset.
+
+For production, a properly-configured, managed, standalone database is recommended. No matter what database you use, you should plan to back it up regularly.
+
+### Caching Layer
+
+The caching layer serves two main functions:
+
+- Store the results of queries to your data warehouse so that when a chart is loaded twice, it pulls from the cache the second time, speeding up the application and reducing load on your data warehouse.
+- Act as a message broker for the worker, enabling the Alerts & Reports, async queries, and thumbnail caching features.
+
+Most people use Redis for their cache, but Superset supports other options too. See the [cache docs](/docs/configuration/cache/) for more.
+
+### Worker and Beat
+
+This is one or more workers who execute tasks like run async queries or take snapshots of reports and send emails, and a "beat" that acts as the scheduler and tells workers when to perform their tasks. Most installations use Celery for these components.
+
+## Other components
+
+Other components can be incorporated into Superset. The best place to learn about additional configurations is the [Configuration page](/docs/configuration/configuring-superset). For instance, you could set up a load balancer or reverse proxy to implement HTTPS in front of your Superset application, or specify a Mapbox URL to enable geospatial charts, etc.
+
+Superset won't even start without certain configuration settings established, so it's essential to review that page.

docs/versioned_docs/version-6.0.0/installation/docker-builds.mdx

@@ -0,0 +1,175 @@
+---
+title: Docker Builds
+hide_title: true
+sidebar_position: 7
+version: 1
+---
+
+# Docker builds, images and tags
+
+The Apache Superset community extensively uses Docker for development, release,
+and productionizing Superset. This page details our Docker builds and tag naming
+schemes to help users navigate our offerings.
+
+Images are built and pushed to the [Superset Docker Hub repository](
+https://hub.docker.com/r/apache/superset) using GitHub Actions.
+Different sets of images are built and/or published at different times:
+
+- **Published releases** (`release`): published using
+  tags like `5.0.0` and the `latest` tag.
+- **Pull request iterations** (`pull_request`): for each pull request, while
+  we actively build the docker to validate the build, we do
+  not publish those images for security reasons, we simply `docker build --load`
+- **Merges to the main branch** (`push`): resulting in new SHAs, with tags
+  prefixed with `master` for the latest `master` version.
+
+## Build presets
+
+We have a set of build "presets" that each represent a combination of
+parameters for the build, mostly pointing to either different target layer
+for the build, and/or base image.
+
+Here are the build presets that are exposed through the `supersetbot docker` utility:
+
+- `lean`: The default Docker image, including both frontend and backend. Tags
+  without a build_preset are lean builds (ie: `latest`, `5.0.0`, `4.1.2`, ...). `lean`
+  builds do not contain database
+  drivers, meaning you need to install your own. That applies to analytics databases **AND
+  the metadata database**. You'll likely want to layer either `mysqlclient` or `psycopg2-binary`
+  depending on the metadata database you choose for your installation, plus the required
+  drivers to connect to your analytics database(s).
+- `dev`: For development, with a headless browser, dev-related utilities and root access. This
+  includes some commonly used database drivers like `mysqlclient`, `psycopg2-binary` and
+  some other used for development/CI
+- `py311`, e.g., Py311: Similar to lean but with a different Python version (in this example, 3.11).
+- `ci`: For certain CI workloads.
+- `websocket`: For Superset clusters supporting advanced features.
+- `dockerize`: Used by Helm in initContainers to wait for database dependencies to be available.
+
+## Key tags examples
+
+- `latest`: The latest official release build
+- `latest-dev`: the `-dev` image of the latest official release build, with a
+  headless browser and root access.
+- `master`: The latest build from the `master` branch, implicitly the lean build
+  preset
+- `master-dev`: Similar to `master` but includes a headless browser and root access.
+- `pr-5252`: The latest commit in PR 5252.
+- `30948dc401b40982cb7c0dbf6ebbe443b2748c1b-dev`: A build for
+  this specific SHA, which could be from a `master` merge, or release.
+- `websocket-latest`: The WebSocket image for use in a Superset cluster.
+
+For insights or modifications to the build matrix and tagging conventions,
+check the [supersetbot docker](https://github.com/apache-superset/supersetbot)
+subcommand and the [docker.yml](https://github.com/apache/superset/blob/master/.github/workflows/docker.yml)
+GitHub action.
+
+## Building your own production Docker image
+
+Every Superset deployment will require its own set of drivers depending on the data warehouse(s),
+etc. so we recommend that users build their own Docker image by extending the `lean` image.
+
+Here's an example Dockerfile that does this. Follow the in-line comments to customize it for
+your desired Superset version and database drivers. The comments also note that a certain feature flag will
+have to be enabled in your config file.
+
+You would build the image with `docker build -t mysuperset:latest .` or `docker build -t ourcompanysuperset:5.0.0 .`
+
+```Dockerfile
+# change this to apache/superset:5.0.0 or whatever version you want to build from;
+# otherwise the default is the latest commit on GitHub master branch
+FROM apache/superset:master
+
+USER root
+
+# Set environment variable for Playwright
+ENV PLAYWRIGHT_BROWSERS_PATH=/usr/local/share/playwright-browsers
+
+# Install packages using uv into the virtual environment
+# Superset started using uv after the 4.1 branch; if you are building from apache/superset:4.1.x or an older version,
+# replace the first two lines with RUN pip install \
+RUN . /app/.venv/bin/activate && \
+    uv pip install \
+    # install psycopg2 for using PostgreSQL metadata store - could be a MySQL package if using that backend:
+    psycopg2-binary \
+    # add the driver(s) for your data warehouse(s), in this example we're showing for Microsoft SQL Server:
+    pymssql \
+    # package needed for using single-sign on authentication:
+    Authlib \
+    # openpyxl to be able to upload Excel files
+    openpyxl \
+    # Pillow for Alerts & Reports to generate PDFs of dashboards
+    Pillow \
+    # install Playwright for taking screenshots for Alerts & Reports. This assumes the feature flag PLAYWRIGHT_REPORTS_AND_THUMBNAILS is enabled
+    # That feature flag will default to True starting in 6.0.0
+    # Playwright works only with Chrome.
+    # If you are still using Selenium instead of Playwright, you would instead install here the selenium package and a headless browser & webdriver
+    playwright \
+    && playwright install-deps \
+    && PLAYWRIGHT_BROWSERS_PATH=/usr/local/share/playwright-browsers playwright install chromium
+
+# Switch back to the superset user
+USER superset
+
+CMD ["/app/docker/entrypoints/run-server.sh"]
+```
+
+## Key ARGs in Dockerfile
+
+- `BUILD_TRANSLATIONS`: whether to build the translations into the image. For the
+  frontend build this tells webpack to strip out all locales other than `en` from
+  the `moment-timezone` library. For the backendthis skips compiling the
+  `*.po` translation files
+- `DEV_MODE`: whether to skip the frontend build, this is used by our `docker-compose` dev setup
+  where we mount the local volume and build using `webpack` in `--watch` mode, meaning as you
+  alter the code in the local file system, webpack, from within a docker image used for this
+  purpose, will constantly rebuild the frontend as you go. This ARG enables the initial
+  `docker-compose` build to take much less time and resources
+- `INCLUDE_CHROMIUM`: whether to include chromium in the backend build so that it can be
+  used as a headless browser for workloads related to "Alerts & Reports" and thumbnail generation
+- `INCLUDE_FIREFOX`: same as above, but for firefox
+- `PY_VER`: specifying the base image for the python backend, we don't recommend altering
+  this setting if you're not working on forwards or backwards compatibility
+
+## Caching
+
+To accelerate builds, we follow Docker best practices and use `apache/superset-cache`.
+
+## About database drivers
+
+Our docker images come with little to zero database driver support since
+each environment requires different drivers, and maintaining a build with
+wide database support would be both challenging (dozens of databases,
+python drivers, and os dependencies) and inefficient (longer
+build times, larger images, lower layer cache hit rate, ...).
+
+For production use cases, we recommend that you derive our `lean` image(s) and
+add database support for the database you need.
+
+## On supporting different platforms (namely arm64 AND amd64)
+
+Currently all automated builds are multi-platform, supporting both `linux/arm64`
+and `linux/amd64`. This enables higher level constructs like `helm` and
+`docker compose` to point to these images and effectively be multi-platform
+as well.
+
+Pull requests and master builds
+are one-image-per-platform so that they can be parallelized and the
+build matrix for those is more sparse as we don't need to build every
+build preset on every platform, and generally can be more selective here.
+For those builds, we suffix tags with `-arm` where it applies.
+
+### Working with Apple silicon
+
+Apple's current generation of computers uses ARM-based CPUs, and Docker
+running on MACs seem to require `linux/arm64/v8` (at least one user's M2 was
+configured in that way). Setting the environment
+variable `DOCKER_DEFAULT_PLATFORM` to `linux/amd64` seems to function in
+term of leveraging, and building upon the Superset builds provided here.
+
+```bash
+export DOCKER_DEFAULT_PLATFORM=linux/amd64
+```
+
+Presumably, `linux/arm64/v8` would be more optimized for this generation
+of chips, but less compatible across the ARM ecosystem.

docs/versioned_docs/version-6.0.0/installation/docker-compose.mdx

@@ -0,0 +1,286 @@
+---
+title: Docker Compose
+hide_title: true
+sidebar_position: 5
+version: 1
+---
+
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+# Using Docker Compose
+
+<img src={useBaseUrl("/img/docker-compose.webp" )} width="150" />
+<br /><br />
+
+:::caution
+Since `docker compose` is primarily designed to run a set of containers on **a single host**
+and can't support requirements for **high availability**, we do not support nor recommend
+using our `docker compose` constructs to support production-type use-cases. For single host
+environments, we recommend using [minikube](https://minikube.sigs.k8s.io/docs/start/) along
+with our [installing on k8s](https://superset.apache.org/docs/installation/running-on-kubernetes)
+documentation.
+:::
+
+As mentioned in our [quickstart guide](/docs/quickstart), the fastest way to try
+Superset locally is using Docker Compose on a Linux or Mac OSX
+computer. Superset does not have official support for Windows. It's also the easiest
+way to launch a fully functioning **development environment** quickly.
+
+Note that there are 4 major ways we support to run `docker compose`:
+
+1. **docker-compose.yml:** for interactive development, where we mount your local folder with the
+  frontend/backend files that you can edit and experience the changes you
+  make in the app in real time
+1. **docker-compose-light.yml:** a lightweight configuration with minimal services (database,
+  Superset app, and frontend dev server) for development. Uses in-memory caching instead of Redis
+  and is designed for running multiple instances simultaneously
+1. **docker-compose-non-dev.yml** where we just build a more immutable image based on the
+  local branch and get all the required images running. Changes in the local branch
+  at the time you fire this up will be reflected, but changes to the code
+  while `up` won't be reflected in the app
+1. **docker-compose-image-tag.yml** where we fetch an image from docker-hub say for the
+  `5.0.0` release for instance, and fire it up so you can try it. Here what's in
+  the local branch has no effects on what's running, we just fetch and run
+  pre-built images from docker-hub. For `docker compose` to work along with the
+  Postgres image it boots up, you'll want to point to a `-dev`-suffixed TAG, as in
+  `export TAG=5.0.0-dev` or `export TAG=4.1.2-dev`, with `latest-dev` being the default.
+  The `dev` builds include the `psycopg2-binary` required to connect
+  to the Postgres database launched as part of the `docker compose` builds.
+
+More on these approaches after setting up the requirements for either.
+
+## Requirements
+
+Note that this documentation assumes that you have [Docker](https://www.docker.com) and
+[git](https://git-scm.com/) installed. Note also that we used to use `docker-compose` but that
+is on the path to deprecation so we now use `docker compose` instead.
+
+## 1. Clone Superset's GitHub repository
+
+[Clone Superset's repo](https://github.com/apache/superset) in your terminal with the
+following command:
+
+```bash
+git clone --depth=1  https://github.com/apache/superset.git
+```
+
+Once that command completes successfully, you should see a new `superset` folder in your
+current directory.
+
+## 2. Launch Superset Through Docker Compose
+
+First let's assume you're familiar with `docker compose` mechanics. Here we'll refer generally
+to `docker compose up` even though in some cases you may want to force a check for newer remote
+images using `docker compose pull`, force a build with `docker compose build` or force a build
+on latest base images using `docker compose build --pull`. In most cases though, the simple
+`up` command should do just fine. Refer to docker compose docs for more information on the topic.
+
+### Option #1 - for an interactive development environment
+
+```bash
+# The --build argument insures all the layers are up-to-date
+docker compose up --build
+```
+
+:::tip
+When running in development mode the `superset-node`
+container needs to finish building assets in order for the UI to render properly. If you would just
+like to try out Superset without making any code changes follow the steps documented for
+`production` or a specific version below.
+:::
+
+:::tip
+By default, we mount the local superset-frontend folder here and run `npm install` as well
+as `npm run dev` which triggers webpack to compile/bundle the frontend code. Depending
+on your local setup, especially if you have less than 16GB of memory,  it may be very slow to
+perform those operations. In this case, we recommend you set the env var
+`BUILD_SUPERSET_FRONTEND_IN_DOCKER` to `false`, and to run this locally instead in a terminal.
+Simply trigger `npm i && npm run dev`, this should be MUCH faster.
+:::
+
+:::tip
+Sometimes, your npm-related state can get out-of-wack, running `npm run prune` from
+the `superset-frontend/` folder will nuke the various' packages `node_module/` folders
+and help you start fresh. In the context of `docker compose` setting
+`export NPM_RUN_PRUNE=true` prior to running `docker compose up` will trigger that
+from within docker. This will slow down the startup, but will fix various npm-related issues.
+:::
+
+### Option #2 - lightweight development with multiple instances
+
+For a lighter development setup that uses fewer resources and supports running multiple instances:
+
+```bash
+# Single lightweight instance (default port 9001)
+docker compose -f docker-compose-light.yml up
+
+# Multiple instances with different ports
+NODE_PORT=9001 docker compose -p superset-1 -f docker-compose-light.yml up
+NODE_PORT=9002 docker compose -p superset-2 -f docker-compose-light.yml up
+NODE_PORT=9003 docker compose -p superset-3 -f docker-compose-light.yml up
+```
+
+This configuration includes:
+- PostgreSQL database (internal network only)
+- Superset application server
+- Frontend development server with webpack hot reloading
+- In-memory caching (no Redis)
+- Isolated volumes and networks per instance
+
+Access each instance at `http://localhost:{NODE_PORT}` (e.g., `http://localhost:9001`).
+
+### Option #3 - build a set of immutable images from the local branch
+
+```bash
+docker compose -f docker-compose-non-dev.yml up
+```
+
+### Option #4 - boot up an official release
+
+```bash
+# Set the version you want to run
+export TAG=5.0.0
+# Fetch the tag you're about to check out (assuming you shallow-cloned the repo)
+git fetch --depth=1 origin tag $TAG
+# Could also fetch all tags too if you've got bandwidth to spare
+# git fetch --tags
+# Checkout the corresponding git ref
+git checkout $TAG
+# Fire up docker compose
+docker compose -f docker-compose-image-tag.yml up
+```
+
+Here various release tags, github SHA, and latest `master` can be referenced by the TAG env var.
+Refer to the docker-related documentation to learn more about existing tags you can point to
+from Docker Hub.
+
+:::note
+For option #2 and #3, we recommend checking out the release tag from the git repository
+(ie: `git checkout 5.0.0`) for more guaranteed results. This ensures that the `docker-compose.*.yml`
+configurations and that the mounted `docker/` scripts are in sync with the image you are
+looking to fire up.
+:::
+
+## `docker compose` tips & configuration
+
+:::caution
+All of the content belonging to a Superset instance - charts, dashboards, users, etc. - is stored in
+its metadata database. In production, this database should be backed up.  The default installation
+with docker compose will store that data in a PostgreSQL database contained in a Docker
+[volume](https://docs.docker.com/storage/volumes/), which is not backed up.
+
+Again, **THE DOCKER-COMPOSE INSTALLATION IS NOT PRODUCTION-READY OUT OF THE BOX.**
+
+:::
+
+You should see a stream of logging output from the containers being launched on your machine. Once
+this output slows, you should have a running instance of Superset on your local machine!  To avoid
+the wall of text on future runs, add the `-d` option to the end of the `docker compose up` command.
+
+### Configuring Further
+
+The following is for users who want to configure how Superset runs in Docker Compose; otherwise, you
+can skip to the next section.
+
+You can install additional python packages and apply config overrides by following the steps
+mentioned in [docker/README.md](https://github.com/apache/superset/tree/master/docker#configuration)
+
+Note that `docker/.env` sets the default environment variables for all the docker images
+used by `docker compose`, and that `docker/.env-local` can be used to override those defaults.
+Also note that `docker/.env-local` is referenced in our `.gitignore`,
+preventing developers from risking committing potentially sensitive configuration to the repository.
+
+One important variable is `SUPERSET_LOAD_EXAMPLES` which determines whether the `superset_init`
+container will populate example data and visualizations into the metadata database. These examples
+are helpful for learning and testing out Superset but unnecessary for experienced users and
+production deployments. The loading process can sometimes take a few minutes and a good amount of
+CPU, so you may want to disable it on a resource-constrained device.
+
+For more advanced or dynamic configurations that are typically managed in a `superset_config.py` file
+located in your `PYTHONPATH`, note that it can be done by providing a
+`docker/pythonpath_dev/superset_config_docker.py` that will be ignored by git
+(preventing you to commit/push your local configuration back to the repository).
+The mechanics of this are in `docker/pythonpath_dev/superset_config.py` where you can see
+that the logic runs a `from superset_config_docker import *`
+
+:::note
+Users often want to connect to other databases from Superset. Currently, the easiest way to
+do this is to modify the `docker-compose-non-dev.yml` file and add your database as a service that
+the other services depend on (via `x-superset-depends-on`). Others have attempted to set
+`network_mode: host` on the Superset services, but these generally break the installation,
+because the configuration requires use of the Docker Compose DNS resolver for the service names.
+If you have a good solution for this, let us know!
+:::
+
+:::note
+Superset uses [Scarf Gateway](https://about.scarf.sh/scarf-gateway) to collect telemetry
+data. Knowing the installation counts for different Superset versions informs the project's
+decisions about patching and long-term support. Scarf purges personally identifiable information
+(PII) and provides only aggregated statistics.
+
+To opt-out of this data collection for packages downloaded through the Scarf Gateway by your docker
+compose based installation, edit the `x-superset-image:` line in your `docker-compose.yml` and
+`docker-compose-non-dev.yml` files, replacing `apachesuperset.docker.scarf.sh/apache/superset` with
+`apache/superset` to pull the image directly from Docker Hub.
+
+To disable the Scarf telemetry pixel, set the `SCARF_ANALYTICS` environment variable to `False` in
+your terminal and/or in your `docker/.env` file.
+:::
+
+## 3. Log in to Superset
+
+Your local Superset instance also includes a Postgres server to store your data and is already
+pre-loaded with some example datasets that ship with Superset. You can access Superset now via your
+web browser by visiting `http://localhost:8088`. Note that many browsers now default to `https` - if
+yours is one of them, please make sure it uses `http`.
+
+Log in with the default username and password:
+
+```bash
+username: admin
+```
+
+```bash
+password: admin
+```
+
+## 4. Connecting Superset to your local database instance
+
+When running Superset using `docker` or `docker compose` it runs in its own docker container, as if
+the Superset was running in a separate machine entirely. Therefore attempts to connect to your local
+database with the hostname `localhost` won't work as `localhost` refers to the docker container
+Superset is running in, and not your actual host machine. Fortunately, docker provides an easy way
+to access network resources in the host machine from inside a container, and we will leverage this
+capability to connect to our local database instance.
+
+Here the instructions are for connecting to postgresql (which is running on your host machine) from
+Superset (which is running in its docker container). Other databases may have slightly different
+configurations but gist would be same and boils down to 2 steps -
+
+1. **(Mac users may skip this step)** Configuring the local postgresql/database instance to accept
+public incoming connections. By default, postgresql only allows incoming connections from
+`localhost` and under Docker, unless you use `--network=host`, `localhost` will refer to different
+endpoints on the host machine and in a docker container respectively. Allowing postgresql to accept
+connections from the Docker involves making one-line changes to the files `postgresql.conf` and
+`pg_hba.conf`; you can find helpful links tailored to your OS / PG version on the web easily for
+this task. For Docker it suffices to only whitelist IPs `172.0.0.0/8` instead of `*`, but in any
+case you are _warned_ that doing this in a production database _may_ have disastrous consequences as
+you are opening your database to the public internet.
+1. Instead of `localhost`, try using `host.docker.internal` (Mac users, Ubuntu) or `172.18.0.1`
+(Linux users) as the hostname when attempting to connect to the database. This is a Docker internal
+detail -- what is happening is that, in Mac systems, Docker Desktop creates a dns entry for the
+hostname `host.docker.internal` which resolves to the correct address for the host machine, whereas
+in Linux this is not the case (at least by default). If neither of these 2 hostnames work then you
+may want to find the exact hostname you want to use, for that you can do `ifconfig` or
+`ip addr show` and look at the IP address of `docker0` interface that must have been created by
+Docker for you. Alternately if you don't even see the `docker0` interface try (if needed with sudo)
+`docker network inspect bridge` and see if there is an entry for `"Gateway"` and note the IP
+address.
+
+## 4. To build or not to build
+
+When running `docker compose up`, docker will build what is required behind the scene, but
+may use the docker cache if assets already exist. Running `docker compose build` prior to
+`docker compose up` or the equivalent shortcut `docker compose up --build` ensures that your
+docker images matche the definition in the repository. This should only apply to the main
+docker-compose.yml file (default) and not to the alternative methods defined above.

docs/versioned_docs/version-6.0.0/installation/installation-methods.mdx

@@ -0,0 +1,56 @@
+---
+title: Installation Methods
+hide_title: true
+sidebar_position: 2
+version: 1
+---
+
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+# Installation Methods
+
+How should you install Superset? Here's a comparison of the different options. It will help if you've first read the [Architecture](/docs/installation/architecture.mdx) page to understand Superset's different components.
+
+The fundamental trade-off is between you needing to do more of the detail work yourself vs. using a more complex deployment route that handles those details.
+
+## [Docker Compose](/docs/installation/docker-compose.mdx)
+
+**Summary:** This takes advantage of containerization while remaining simpler than Kubernetes. This is the best way to try out Superset; it's also useful for developing & contributing back to Superset.
+
+If you're not just demoing the software, you'll need a moderate understanding of Docker to customize your deployment and avoid a few risks. Even when fully-optimized this is not as robust a method as Kubernetes when it comes to large-scale production deployments.
+
+You manage a superset-config.py file and a docker-compose.yml file. Docker Compose brings up all the needed services - the Superset application, a Postgres metadata DB, Redis cache, Celery worker and beat. They are automatically connected to each other.
+
+**Responsibilities**
+
+You will need to back up your metadata DB. That could mean backing up the service running as a Docker container and its volume; ideally you are running Postgres as a service outside of that container and backing up that service.
+
+You will also need to extend the Superset docker image. The default `lean` images do not contain drivers needed to access your metadata database (Postgres or MySQL), nor to access your data warehouse, nor the headless browser needed for Alerts & Reports. You could run a `-dev` image while demoing Superset, which has some of this, but you'll still need to install the driver for your data warehouse. The `-dev` images run as root, which is not recommended for production.
+
+Ideally you will build your own image of Superset that extends `lean`, adding what your deployment needs. See [Building your own production Docker image](/docs/installation/docker-builds/#building-your-own-production-docker-image).
+
+## [Kubernetes (K8s)](/docs/installation/kubernetes.mdx)
+
+**Summary:** This is the best-practice way to deploy a production instance of Superset, but has the steepest skill requirement - someone who knows Kubernetes.
+
+You will deploy Superset into a K8s cluster. The most common method is using the community-maintained Helm chart, though work is now underway to implement [SIP-149 - a Kubernetes Operator for Superset](https://github.com/apache/superset/issues/31408).
+
+A K8s deployment can scale up and down based on usage and deploy rolling updates with zero downtime - features that big deployments appreciate.
+
+**Responsibilities**
+
+You will need to build your own Docker image, and back up your metadata DB, both as described in Docker Compose above. You'll also need to customize your Helm chart values and deploy and maintain your Kubernetes cluster.
+
+## [PyPI (Python)](/docs/installation/pypi.mdx)
+
+**Summary:** This is the only method that requires no knowledge of containers. It requires the most hands-on work to deploy, connect, and maintain each component.
+
+You install Superset as a Python package and run it that way, providing your own metadata database. Superset has documentation on how to install this way, but it is updated infrequently.
+
+If you want caching, you'll set up Redis or RabbitMQ. If you want Alerts & Reports, you'll set up Celery.
+
+**Responsibilities**
+
+You will need to get the component services running and communicating with each other. You'll need to arrange backups of your metadata database.
+
+When upgrading, you'll need to manage the system environment and packages and ensure all components have functional dependencies.

docs/versioned_docs/version-6.0.0/installation/kubernetes.mdx

@@ -0,0 +1,446 @@
+---
+title:  Kubernetes
+hide_title: true
+sidebar_position: 3
+version: 1
+---
+
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+# Installing on Kubernetes
+
+<img src={useBaseUrl("/img/k8s.png" )} width="150" />
+<br /><br />
+
+Running Superset on Kubernetes is supported with the provided [Helm](https://helm.sh/) chart
+found in the official [Superset helm repository](https://apache.github.io/superset/index.yaml).
+
+## Prerequisites
+
+- A Kubernetes cluster
+- Helm installed
+
+:::note
+For simpler, single host environments, we recommend using
+[minikube](https://minikube.sigs.k8s.io/docs/start/) which is easy to setup on many platforms
+and works fantastically well with the Helm chart referenced here.
+:::
+
+## Running
+
+1. Add the Superset helm repository
+
+```sh
+helm repo add superset https://apache.github.io/superset
+"superset" has been added to your repositories
+```
+
+2. View charts in repo
+
+```sh
+helm search repo superset
+NAME                    CHART VERSION   APP VERSION     DESCRIPTION
+superset/superset       0.1.1           1.0             Apache Superset is a modern, enterprise-ready b...
+```
+
+3. Configure your setting overrides
+
+Just like any typical Helm chart, you'll need to craft a `values.yaml` file that would define/override any of the values exposed into the default [values.yaml](https://github.com/apache/superset/tree/master/helm/superset/values.yaml), or from any of the dependent charts it depends on:
+
+- [bitnami/redis](https://artifacthub.io/packages/helm/bitnami/redis)
+- [bitnami/postgresql](https://artifacthub.io/packages/helm/bitnami/postgresql)
+
+More info down below on some important overrides you might need.
+
+4. Install and run
+
+```sh
+helm upgrade --install --values my-values.yaml superset superset/superset
+```
+
+You should see various pods popping up, such as:
+
+```sh
+kubectl get pods
+NAME                                    READY   STATUS      RESTARTS   AGE
+superset-celerybeat-7cdcc9575f-k6xmc    1/1     Running     0          119s
+superset-f5c9c667-dw9lp                 1/1     Running     0          4m7s
+superset-f5c9c667-fk8bk                 1/1     Running     0          4m11s
+superset-init-db-zlm9z                  0/1     Completed   0          111s
+superset-postgresql-0                   1/1     Running     0          6d20h
+superset-redis-master-0                 1/1     Running     0          6d20h
+superset-worker-75b48bbcc-jmmjr         1/1     Running     0          4m8s
+superset-worker-75b48bbcc-qrq49         1/1     Running     0          4m12s
+```
+
+The exact list will depend on some of your specific configuration overrides but you should generally expect:
+
+- N `superset-xxxx-yyyy` and `superset-worker-xxxx-yyyy` pods (depending on your `supersetNode.replicaCount` and `supersetWorker.replicaCount` values)
+- 1 `superset-postgresql-0` depending on your postgres settings
+- 1 `superset-redis-master-0` depending on your redis settings
+- 1 `superset-celerybeat-xxxx-yyyy` pod if you have `supersetCeleryBeat.enabled = true` in your values overrides
+
+1. Access it
+
+The chart will publish appropriate services to expose the Superset UI internally within your k8s cluster. To access it externally you will have to either:
+
+- Configure the Service as a `LoadBalancer` or `NodePort`
+- Set up an `Ingress` for it - the chart includes a definition, but will need to be tuned to your needs (hostname, tls, annotations etc...)
+- Run `kubectl port-forward superset-xxxx-yyyy :8088` to directly tunnel one pod's port into your localhost
+
+Depending how you configured external access, the URL will vary. Once you've identified the appropriate URL you can log in with:
+
+- user: `admin`
+- password: `admin`
+
+## Important settings
+
+### Security settings
+
+Default security settings and passwords are included but you **MUST** update them to run `prod` instances, in particular:
+
+```yaml
+postgresql:
+  postgresqlPassword: superset
+```
+
+Make sure, you set a unique strong complex alphanumeric string for your SECRET_KEY and use a tool to help you generate
+a sufficiently random sequence.
+
+- To generate a good key you can run, `openssl rand -base64 42`
+
+```yaml
+configOverrides:
+  secret: |
+    SECRET_KEY = 'YOUR_OWN_RANDOM_GENERATED_SECRET_KEY'
+```
+
+If you want to change the previous secret key then you should rotate the keys.
+Default secret key for kubernetes deployment is `thisISaSECRET_1234`
+
+```yaml
+configOverrides:
+  my_override: |
+    PREVIOUS_SECRET_KEY = 'YOUR_PREVIOUS_SECRET_KEY'
+    SECRET_KEY = 'YOUR_OWN_RANDOM_GENERATED_SECRET_KEY'
+init:
+  command:
+    - /bin/sh
+    - -c
+    - |
+      . {{ .Values.configMountPath }}/superset_bootstrap.sh
+      superset re-encrypt-secrets
+      . {{ .Values.configMountPath }}/superset_init.sh
+```
+
+:::note
+Superset uses [Scarf Gateway](https://about.scarf.sh/scarf-gateway) to collect telemetry data.  Knowing the installation counts for different Superset versions informs the  project's decisions about patching and long-term support. Scarf purges personally identifiable information (PII) and provides only aggregated statistics.
+
+To opt-out of this data collection in your Helm-based installation, edit the `repository:` line in your `helm/superset/values.yaml` file, replacing `apachesuperset.docker.scarf.sh/apache/superset` with `apache/superset` to pull the image directly from Docker Hub.
+:::
+
+### Dependencies
+
+Install additional packages and do any other bootstrap configuration in the bootstrap script.
+For production clusters it's recommended to build own image with this step done in CI.
+
+:::note
+
+Superset requires a Python DB-API database driver and a SQLAlchemy
+dialect to be installed for each datastore you want to connect to.
+
+See [Install Database Drivers](/docs/configuration/databases) for more information.
+It is recommended that you refer to versions listed in
+[pyproject.toml](https://github.com/apache/superset/blob/master/pyproject.toml)
+instead of hard-coding them in your bootstrap script, as seen below.
+
+:::
+
+The following example installs the drivers for BigQuery and Elasticsearch, allowing you to connect to these data sources within your Superset setup:
+
+```yaml
+bootstrapScript: |
+  #!/bin/bash
+  uv pip install .[postgres] \
+    .[bigquery] \
+    .[elasticsearch] &&\
+  if [ ! -f ~/bootstrap ]; then echo "Running Superset with uid {{ .Values.runAsUser }}" > ~/bootstrap; fi
+```
+
+### superset_config.py
+
+The default `superset_config.py` is fairly minimal and you will very likely need to extend it. This is done by specifying one or more key/value entries in `configOverrides`, e.g.:
+
+```yaml
+configOverrides:
+  my_override: |
+    # This will make sure the redirect_uri is properly computed, even with SSL offloading
+    ENABLE_PROXY_FIX = True
+    FEATURE_FLAGS = {
+        "DYNAMIC_PLUGINS": True
+    }
+```
+
+Those will be evaluated as Helm templates and therefore will be able to reference other `values.yaml` variables e.g. `{{ .Values.ingress.hosts[0] }}` will resolve to your ingress external domain.
+
+The entire `superset_config.py` will be installed as a secret, so it is safe to pass sensitive parameters directly... however it might be more readable to use secret env variables for that.
+
+Full python files can be provided by running `helm upgrade --install --values my-values.yaml --set-file configOverrides.oauth=set_oauth.py`
+
+### Environment Variables
+
+Those can be passed as key/values either with `extraEnv` or `extraSecretEnv` if they're sensitive. They can then be referenced from `superset_config.py` using e.g. `os.environ.get("VAR")`.
+
+```yaml
+extraEnv:
+  SMTP_HOST: smtp.gmail.com
+  SMTP_USER: user@gmail.com
+  SMTP_PORT: "587"
+  SMTP_MAIL_FROM: user@gmail.com
+
+extraSecretEnv:
+  SMTP_PASSWORD: xxxx
+
+configOverrides:
+  smtp: |
+    import ast
+    SMTP_HOST = os.getenv("SMTP_HOST","localhost")
+    SMTP_STARTTLS = ast.literal_eval(os.getenv("SMTP_STARTTLS", "True"))
+    SMTP_SSL = ast.literal_eval(os.getenv("SMTP_SSL", "False"))
+    SMTP_USER = os.getenv("SMTP_USER","superset")
+    SMTP_PORT = os.getenv("SMTP_PORT",25)
+    SMTP_PASSWORD = os.getenv("SMTP_PASSWORD","superset")
+```
+
+### System packages
+
+If new system packages are required, they can be installed before application startup by overriding the container's `command`, e.g.:
+
+```yaml
+supersetWorker:
+  command:
+    - /bin/sh
+    - -c
+    - |
+      apt update
+      apt install -y somepackage
+      apt autoremove -yqq --purge
+      apt clean
+
+      # Run celery worker
+      . {{ .Values.configMountPath }}/superset_bootstrap.sh; celery --app=superset.tasks.celery_app:app worker
+```
+
+### Data sources
+
+Data source definitions can be automatically declared by providing key/value yaml definitions in `extraConfigs`:
+
+```yaml
+extraConfigs:
+  import_datasources.yaml: |
+    databases:
+    - allow_file_upload: true
+      allow_ctas: true
+      allow_cvas: true
+      database_name: example-db
+      extra: "{\r\n    \"metadata_params\": {},\r\n    \"engine_params\": {},\r\n    \"\
+        metadata_cache_timeout\": {},\r\n    \"schemas_allowed_for_file_upload\": []\r\n\
+        }"
+      sqlalchemy_uri: example://example-db.local
+      tables: []
+```
+
+Those will also be mounted as secrets and can include sensitive parameters.
+
+## Configuration Examples
+
+### Setting up OAuth
+
+:::note
+
+OAuth setup requires that the [authlib](https://authlib.org/) Python library is installed. This can
+be done using `pip` by updating the `bootstrapScript`. See the [Dependencies](#dependencies) section
+for more information.
+
+:::
+
+```yaml
+extraEnv:
+  AUTH_DOMAIN: example.com
+
+extraSecretEnv:
+  GOOGLE_KEY: xxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com
+  GOOGLE_SECRET: xxxxxxxxxxxxxxxxxxxxxxxx
+
+configOverrides:
+  enable_oauth: |
+    # This will make sure the redirect_uri is properly computed, even with SSL offloading
+    ENABLE_PROXY_FIX = True
+
+    from flask_appbuilder.security.manager import AUTH_OAUTH
+    AUTH_TYPE = AUTH_OAUTH
+    OAUTH_PROVIDERS = [
+        {
+            "name": "google",
+            "icon": "fa-google",
+            "token_key": "access_token",
+            "remote_app": {
+                "client_id": os.getenv("GOOGLE_KEY"),
+                "client_secret": os.getenv("GOOGLE_SECRET"),
+                "api_base_url": "https://www.googleapis.com/oauth2/v2/",
+                "client_kwargs": {"scope": "email profile"},
+                "request_token_url": None,
+                "access_token_url": "https://accounts.google.com/o/oauth2/token",
+                "authorize_url": "https://accounts.google.com/o/oauth2/auth",
+                "authorize_params": {"hd": os.getenv("AUTH_DOMAIN", "")}
+            },
+        }
+    ]
+
+    # Map Authlib roles to superset roles
+    AUTH_ROLE_ADMIN = 'Admin'
+    AUTH_ROLE_PUBLIC = 'Public'
+
+    # Will allow user self registration, allowing to create Flask users from Authorized User
+    AUTH_USER_REGISTRATION = True
+
+    # The default user self registration role
+    AUTH_USER_REGISTRATION_ROLE = "Admin"
+```
+
+### Enable Alerts and Reports
+
+For this, as per the [Alerts and Reports doc](/docs/configuration/alerts-reports), you will need to:
+
+#### Install a supported webdriver in the Celery worker
+
+This is done either by using a custom image that has the webdriver pre-installed, or installing at startup time by overriding the `command`. Here's a working example for `chromedriver`:
+
+```yaml
+supersetWorker:
+  command:
+    - /bin/sh
+    - -c
+    - |
+      # Install chrome webdriver
+      # See https://github.com/apache/superset/blob/4fa3b6c7185629b87c27fc2c0e5435d458f7b73d/docs/src/pages/docs/installation/email_reports.mdx
+      apt-get update
+      apt-get install -y wget
+      wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
+      apt-get install -y --no-install-recommends ./google-chrome-stable_current_amd64.deb
+      wget https://chromedriver.storage.googleapis.com/88.0.4324.96/chromedriver_linux64.zip
+      apt-get install -y zip
+      unzip chromedriver_linux64.zip
+      chmod +x chromedriver
+      mv chromedriver /usr/bin
+      apt-get autoremove -yqq --purge
+      apt-get clean
+      rm -f google-chrome-stable_current_amd64.deb chromedriver_linux64.zip
+
+      # Run
+      . {{ .Values.configMountPath }}/superset_bootstrap.sh; celery --app=superset.tasks.celery_app:app worker
+```
+
+#### Run the Celery beat
+
+This pod will trigger the scheduled tasks configured in the alerts and reports UI section:
+
+```yaml
+supersetCeleryBeat:
+  enabled: true
+```
+
+#### Configure the appropriate Celery jobs and SMTP/Slack settings
+
+```yaml
+extraEnv:
+  SMTP_HOST: smtp.gmail.com
+  SMTP_USER: user@gmail.com
+  SMTP_PORT: "587"
+  SMTP_MAIL_FROM: user@gmail.com
+
+extraSecretEnv:
+  SLACK_API_TOKEN: xoxb-xxxx-yyyy
+  SMTP_PASSWORD: xxxx-yyyy
+
+configOverrides:
+  feature_flags: |
+    import ast
+
+    FEATURE_FLAGS = {
+        "ALERT_REPORTS": True
+    }
+
+    SMTP_HOST = os.getenv("SMTP_HOST","localhost")
+    SMTP_STARTTLS = ast.literal_eval(os.getenv("SMTP_STARTTLS", "True"))
+    SMTP_SSL = ast.literal_eval(os.getenv("SMTP_SSL", "False"))
+    SMTP_USER = os.getenv("SMTP_USER","superset")
+    SMTP_PORT = os.getenv("SMTP_PORT",25)
+    SMTP_PASSWORD = os.getenv("SMTP_PASSWORD","superset")
+    SMTP_MAIL_FROM = os.getenv("SMTP_MAIL_FROM","superset@superset.com")
+
+    SLACK_API_TOKEN = os.getenv("SLACK_API_TOKEN",None)
+  celery_conf: |
+    from celery.schedules import crontab
+
+    class CeleryConfig:
+      broker_url = f"redis://{env('REDIS_HOST')}:{env('REDIS_PORT')}/0"
+      imports = (
+          "superset.sql_lab",
+          "superset.tasks.cache",
+          "superset.tasks.scheduler",
+      )
+      result_backend = f"redis://{env('REDIS_HOST')}:{env('REDIS_PORT')}/0"
+      task_annotations = {
+          "sql_lab.get_sql_results": {
+              "rate_limit": "100/s",
+          },
+      }
+      beat_schedule = {
+          "reports.scheduler": {
+              "task": "reports.scheduler",
+              "schedule": crontab(minute="*", hour="*"),
+          },
+          "reports.prune_log": {
+              "task": "reports.prune_log",
+              'schedule': crontab(minute=0, hour=0),
+          },
+          'cache-warmup-hourly': {
+              "task": "cache-warmup",
+              "schedule": crontab(minute="*/30", hour="*"),
+              "kwargs": {
+                  "strategy_name": "top_n_dashboards",
+                  "top_n": 10,
+                  "since": "7 days ago",
+              },
+          }
+      }
+
+    CELERY_CONFIG = CeleryConfig
+  reports: |
+    EMAIL_PAGE_RENDER_WAIT = 60
+    WEBDRIVER_BASEURL = "http://{{ template "superset.fullname" . }}:{{ .Values.service.port }}/"
+    WEBDRIVER_BASEURL_USER_FRIENDLY = "https://www.example.com/"
+    WEBDRIVER_TYPE= "chrome"
+    WEBDRIVER_OPTION_ARGS = [
+        "--force-device-scale-factor=2.0",
+        "--high-dpi-support=2.0",
+        "--headless",
+        "--disable-gpu",
+        "--disable-dev-shm-usage",
+        # This is required because our process runs as root (in order to install pip packages)
+        "--no-sandbox",
+        "--disable-setuid-sandbox",
+        "--disable-extensions",
+    ]
+```
+
+### Load the Examples data and dashboards
+
+If you are trying Superset out and want some data and dashboards to explore, you can load some examples by creating a `my_values.yaml` and deploying it as described above in the **Configure your setting overrides** step of the **Running** section.
+To load the examples, add the following to the `my_values.yaml` file:
+
+```yaml
+init:
+  loadExamples: true
+```

docs/versioned_docs/version-6.0.0/installation/pypi.mdx

@@ -0,0 +1,164 @@
+---
+title: PyPI
+hide_title: true
+sidebar_position: 4
+version: 1
+---
+
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+# Installing Superset from PyPI
+
+<img src={useBaseUrl("/img/pypi.png" )} width="150" />
+<br /><br />
+
+This page describes how to install Superset using the `apache_superset` package [published on PyPI](https://pypi.org/project/apache_superset/).
+
+## OS Dependencies
+
+Superset stores database connection information in its metadata database. For that purpose, we use
+the cryptography Python library to encrypt connection passwords. Unfortunately, this library has OS
+level dependencies.
+
+**Debian and Ubuntu**
+
+Ubuntu **24.04** uses python 3.12 per default, which currently is not supported by Superset. You need to add a second python installation of 3.11 and install the required additional dependencies.
+```bash
+sudo add-apt-repository ppa:deadsnakes/ppa
+sudo apt update
+sudo apt install python3.11 python3.11-dev python3.11-venv build-essential libssl-dev libffi-dev libsasl2-dev libldap2-dev default-libmysqlclient-dev
+```
+
+In Ubuntu **20.04 and 22.04** the following command will ensure that the required dependencies are installed:
+
+```bash
+sudo apt-get install build-essential libssl-dev libffi-dev python3-dev python3-pip libsasl2-dev libldap2-dev default-libmysqlclient-dev
+```
+
+In Ubuntu **before 20.04** the following command will ensure that the required dependencies are installed:
+
+```bash
+sudo apt-get install build-essential libssl-dev libffi-dev python-dev python-pip libsasl2-dev libldap2-dev default-libmysqlclient-dev
+```
+
+**Fedora and RHEL-derivative Linux distributions**
+
+Install the following packages using the `yum` package manager:
+
+```bash
+sudo yum install gcc gcc-c++ libffi-devel python-devel python-pip python-wheel openssl-devel cyrus-sasl-devel openldap-devel
+```
+
+In more recent versions of CentOS and Fedora, you may need to install a slightly different set of packages using `dnf`:
+
+```bash
+sudo dnf install gcc gcc-c++ libffi-devel python3-devel python3-pip python3-wheel openssl-devel cyrus-sasl-devel openldap-devel
+```
+
+Also, on CentOS, you may need to upgrade pip for the install to work:
+
+```bash
+pip3 install --upgrade pip
+```
+
+**Mac OS X**
+
+If you're not on the latest version of OS X, we recommend upgrading because we've found that many
+issues people have run into are linked to older versions of Mac OS X. After updating, install the
+latest version of XCode command line tools:
+
+```bash
+xcode-select --install
+```
+
+We don't recommend using the system installed Python. Instead, first install the
+[homebrew](https://brew.sh/) manager and then run the following commands:
+
+```bash
+brew install readline pkg-config libffi openssl mysql postgresql@14
+```
+
+You should install a recent version of Python. Refer to the
+[pyproject.toml](https://github.com/apache/superset/blob/master/pyproject.toml) file for a list of Python
+versions officially supported by Superset. We'd recommend using a Python version manager
+like [pyenv](https://github.com/pyenv/pyenv)
+(and also [pyenv-virtualenv](https://github.com/pyenv/pyenv-virtualenv)).
+
+Let's also make sure we have the latest version of `pip` and `setuptools`:
+
+```bash
+pip install --upgrade setuptools pip
+```
+
+Lastly, you may need to set LDFLAGS and CFLAGS for certain Python packages to properly build. You can export these variables with:
+
+```bash
+export LDFLAGS="-L$(brew --prefix openssl)/lib"
+export CFLAGS="-I$(brew --prefix openssl)/include"
+```
+
+These will now be available when pip installing requirements.
+
+## Python Virtual Environment
+
+We highly recommend installing Superset inside of a virtual environment.
+
+You can create and activate a virtual environment using the following commands. Ensure you are using a compatible version of python. You might have to explicitly use for example `python3.11` instead of `python3`.
+
+```bash
+# virtualenv is shipped in Python 3.6+ as venv instead of pyvenv.
+# See https://docs.python.org/3.6/library/venv.html
+python3 -m venv venv
+. venv/bin/activate
+```
+
+Or with pyenv-virtualenv:
+
+```bash
+# Here we name the virtual env 'superset'
+pyenv virtualenv superset
+pyenv activate superset
+```
+
+Once you activated your virtual environment, all of the Python packages you install or uninstall
+will be confined to this environment. You can exit the environment by running `deactivate` on the
+command line.
+
+### Installing and Initializing Superset
+
+First, start by installing `apache_superset`:
+
+```bash
+pip install apache_superset
+```
+
+Then, define mandatory configurations, SECRET_KEY and FLASK_APP:
+```bash
+export SUPERSET_SECRET_KEY=YOUR-SECRET-KEY # For production use, make sure this is a strong key, for example generated using `openssl rand -base64 42`. See https://superset.apache.org/docs/configuration/configuring-superset#specifying-a-secret_key
+export FLASK_APP=superset
+```
+
+Then, you need to initialize the database:
+
+```bash
+superset db upgrade
+```
+
+Finish installing by running through the following commands:
+
+```bash
+# Create an admin user in your metadata database (use `admin` as username to be able to load the examples)
+superset fab create-admin
+
+# Load some data to play with
+superset load_examples
+
+# Create default roles and permissions
+superset init
+
+# To start a development web server on port 8088, use -p to bind to another port
+superset run -p 8088 --with-threads --reload --debugger
+```
+
+If everything worked, you should be able to navigate to `hostname:port` in your browser (e.g.
+locally by default at `localhost:8088`) and login using the username and password you created.

docs/versioned_docs/version-6.0.0/installation/upgrading-superset.mdx

@@ -0,0 +1,49 @@
+---
+title: Upgrading Superset
+hide_title: true
+sidebar_position: 6
+version: 1
+---
+
+# Upgrading Superset
+
+## Docker Compose
+
+First, make sure to shut down the running containers in Docker Compose:
+
+```bash
+docker compose down
+```
+
+Next, update the folder that mirrors the `superset` repo through git:
+
+```bash
+git pull origin master
+```
+
+Then, restart the containers and any changed Docker images will be automatically pulled down:
+
+```bash
+docker compose up
+```
+
+## Updating Superset Manually
+
+To upgrade superset in a native installation, run the following commands:
+
+```bash
+pip install apache_superset --upgrade
+```
+
+## Upgrading the Metadata Database
+
+Migrate the metadata database by running:
+
+```bash
+superset db upgrade
+superset init
+```
+
+While upgrading superset should not delete your charts and dashboards, we recommend following best
+practices and to backup your metadata database before upgrading. Before upgrading production, we
+recommend upgrading in a staging environment and upgrading production finally during off-peak usage.

docs/versioned_docs/version-6.0.0/intro.md

@@ -0,0 +1,227 @@
+---
+hide_title: true
+sidebar_position: 1
+---
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Superset
+
+[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/license/apache-2-0)
+[![Latest Release on Github](https://img.shields.io/github/v/release/apache/superset?sort=semver)](https://github.com/apache/superset/releases/latest)
+[![Build Status](https://github.com/apache/superset/actions/workflows/superset-python-unittest.yml/badge.svg)](https://github.com/apache/superset/actions)
+[![PyPI version](https://badge.fury.io/py/apache_superset.svg)](https://badge.fury.io/py/apache_superset)
+[![Coverage Status](https://codecov.io/github/apache/superset/coverage.svg?branch=master)](https://codecov.io/github/apache/superset)
+[![PyPI](https://img.shields.io/pypi/pyversions/apache_superset.svg?maxAge=2592000)](https://pypi.python.org/pypi/apache_superset)
+[![Get on Slack](https://img.shields.io/badge/slack-join-orange.svg)](http://bit.ly/join-superset-slack)
+[![Documentation](https://img.shields.io/badge/docs-apache.org-blue.svg)](https://superset.apache.org)
+
+<picture width="500">
+  <source
+    width="600"
+    media="(prefers-color-scheme: dark)"
+    src="https://superset.apache.org/img/superset-logo-horiz-dark.svg"
+    alt="Superset logo (dark)"
+  />
+  <img
+    width="600"
+    src="https://superset.apache.org/img/superset-logo-horiz-apache.svg"
+    alt="Superset logo (light)"
+  />
+</picture>
+
+A modern, enterprise-ready business intelligence web application.
+
+[**Why Superset?**](#why-superset) |
+[**Supported Databases**](#supported-databases) |
+[**Installation and Configuration**](#installation-and-configuration) |
+[**Release Notes**](https://github.com/apache/superset/blob/master/RELEASING/README.md#release-notes-for-recent-releases) |
+[**Get Involved**](#get-involved) |
+[**Contributor Guide**](#contributor-guide) |
+[**Resources**](#resources) |
+[**Organizations Using Superset**](https://github.com/apache/superset/blob/master/RESOURCES/INTHEWILD.md)
+
+## Why Superset?
+
+Superset is a modern data exploration and data visualization platform. Superset can replace or augment proprietary business intelligence tools for many teams. Superset integrates well with a variety of data sources.
+
+Superset provides:
+
+- A **no-code interface** for building charts quickly
+- A powerful, web-based **SQL Editor** for advanced querying
+- A **lightweight semantic layer** for quickly defining custom dimensions and metrics
+- Out of the box support for **nearly any SQL** database or data engine
+- A wide array of **beautiful visualizations** to showcase your data, ranging from simple bar charts to geospatial visualizations
+- Lightweight, configurable **caching layer** to help ease database load
+- Highly extensible **security roles and authentication** options
+- An **API** for programmatic customization
+- A **cloud-native architecture** designed from the ground up for scale
+
+## Screenshots & Gifs
+
+**Video Overview**
+
+<!-- File hosted here https://github.com/apache/superset-site/raw/lfs/superset-video-4k.mp4 -->
+
+[superset-video-1080p.webm](https://github.com/user-attachments/assets/b37388f7-a971-409c-96a7-90c4e31322e6)
+
+<br/>
+
+**Large Gallery of Visualizations**
+
+<kbd><img title="Gallery" src="https://superset.apache.org/img/screenshots/gallery.jpg"/></kbd><br/>
+
+**Craft Beautiful, Dynamic Dashboards**
+
+<kbd><img title="View Dashboards" src="https://superset.apache.org/img/screenshots/slack_dash.jpg"/></kbd><br/>
+
+**No-Code Chart Builder**
+
+<kbd><img title="Slice & dice your data" src="https://superset.apache.org/img/screenshots/explore.jpg"/></kbd><br/>
+
+**Powerful SQL Editor**
+
+<kbd><img title="SQL Lab" src="https://superset.apache.org/img/screenshots/sql_lab.jpg"/></kbd><br/>
+
+## Supported Databases
+
+Superset can query data from any SQL-speaking datastore or data engine (Presto, Trino, Athena, [and more](https://superset.apache.org/docs/configuration/databases)) that has a Python DB-API driver and a SQLAlchemy dialect.
+
+Here are some of the major database solutions that are supported:
+
+<p align="center">
+  <img src="https://superset.apache.org/img/databases/redshift.png" alt="redshift" border="0" width="200"/>
+  <img src="https://superset.apache.org/img/databases/google-biquery.png" alt="google-bigquery" border="0" width="200"/>
+  <img src="https://superset.apache.org/img/databases/snowflake.png" alt="snowflake" border="0" width="200"/>
+  <img src="https://superset.apache.org/img/databases/trino.png" alt="trino" border="0" width="150" />
+  <img src="https://superset.apache.org/img/databases/presto.png" alt="presto" border="0" width="200"/>
+  <img src="https://superset.apache.org/img/databases/databricks.png" alt="databricks" border="0" width="160" />
+  <img src="https://superset.apache.org/img/databases/druid.png" alt="druid" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/firebolt.png" alt="firebolt" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/timescale.png" alt="timescale" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/postgresql.png" alt="postgresql" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/mysql.png" alt="mysql" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/mssql-server.png" alt="mssql-server" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/ibm-db2.svg" alt="db2" border="0" width="220" />
+  <img src="https://superset.apache.org/img/databases/sqlite.png" alt="sqlite" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/sybase.png" alt="sybase" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/mariadb.png" alt="mariadb" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/vertica.png" alt="vertica" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/oracle.png" alt="oracle" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/firebird.png" alt="firebird" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/greenplum.png" alt="greenplum" border="0" width="200"  />
+  <img src="https://superset.apache.org/img/databases/clickhouse.png" alt="clickhouse" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/exasol.png" alt="exasol" border="0" width="160" />
+  <img src="https://superset.apache.org/img/databases/monet-db.png" alt="monet-db" border="0" width="200"  />
+  <img src="https://superset.apache.org/img/databases/apache-kylin.png" alt="apache-kylin" border="0" width="80"/>
+  <img src="https://superset.apache.org/img/databases/hologres.png" alt="hologres" border="0" width="80"/>
+  <img src="https://superset.apache.org/img/databases/netezza.png" alt="netezza" border="0" width="80"/>
+  <img src="https://superset.apache.org/img/databases/pinot.png" alt="pinot" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/teradata.png" alt="teradata" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/yugabyte.png" alt="yugabyte" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/databend.png" alt="databend" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/starrocks.png" alt="starrocks" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/doris.png" alt="doris" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/oceanbase.svg" alt="oceanbase" border="0" width="220" />
+  <img src="https://superset.apache.org/img/databases/sap-hana.png" alt="sap-hana" border="0" width="220" />
+  <img src="https://superset.apache.org/img/databases/denodo.png" alt="denodo" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/ydb.svg" alt="ydb" border="0" width="200" />
+  <img src="https://superset.apache.org/img/databases/tdengine.png" alt="TDengine" border="0" width="200" />
+</p>
+
+**A more comprehensive list of supported databases** along with the configuration instructions can be found [here](https://superset.apache.org/docs/configuration/databases).
+
+Want to add support for your datastore or data engine? Read more [here](https://superset.apache.org/docs/frequently-asked-questions#does-superset-work-with-insert-database-engine-here) about the technical requirements.
+
+## Installation and Configuration
+
+Try out Superset's [quickstart](https://superset.apache.org/docs/quickstart/) guide or learn about [the options for production deployments](https://superset.apache.org/docs/installation/architecture/).
+
+## Get Involved
+
+- Ask and answer questions on [StackOverflow](https://stackoverflow.com/questions/tagged/apache-superset) using the **apache-superset** tag
+- [Join our community's Slack](http://bit.ly/join-superset-slack)
+  and please read our [Slack Community Guidelines](https://github.com/apache/superset/blob/master/CODE_OF_CONDUCT.md#slack-community-guidelines)
+- [Join our dev@superset.apache.org Mailing list](https://lists.apache.org/list.html?dev@superset.apache.org). To join, simply send an email to [dev-subscribe@superset.apache.org](mailto:dev-subscribe@superset.apache.org)
+- If you want to help troubleshoot GitHub Issues involving the numerous database drivers that Superset supports, please consider adding your name and the databases you have access to on the [Superset Database Familiarity Rolodex](https://docs.google.com/spreadsheets/d/1U1qxiLvOX0kBTUGME1AHHi6Ywel6ECF8xk_Qy-V9R8c/edit#gid=0)
+- Join Superset's Town Hall and [Operational Model](https://preset.io/blog/the-superset-operational-model-wants-you/) recurring meetings. Meeting info is available on the [Superset Community Calendar](https://superset.apache.org/community)
+
+## Contributor Guide
+
+Interested in contributing? Check out our
+[CONTRIBUTING.md](https://github.com/apache/superset/blob/master/CONTRIBUTING.md)
+to find resources around contributing along with a detailed guide on
+how to set up a development environment.
+
+## Resources
+
+- [Superset "In the Wild"](https://github.com/apache/superset/blob/master/RESOURCES/INTHEWILD.md) - open a PR to add your org to the list!
+- [Feature Flags](https://github.com/apache/superset/blob/master/RESOURCES/FEATURE_FLAGS.md) - the status of Superset's Feature Flags.
+- [Standard Roles](https://github.com/apache/superset/blob/master/RESOURCES/STANDARD_ROLES.md) - How RBAC permissions map to roles.
+- [Superset Wiki](https://github.com/apache/superset/wiki) - Tons of additional community resources: best practices, community content and other information.
+- [Superset SIPs](https://github.com/orgs/apache/projects/170) - The status of Superset's SIPs (Superset Improvement Proposals) for both consensus and implementation status.
+
+Understanding the Superset Points of View
+
+- [The Case for Dataset-Centric Visualization](https://preset.io/blog/dataset-centric-visualization/)
+- [Understanding the Superset Semantic Layer](https://preset.io/blog/understanding-superset-semantic-layer/)
+
+- Getting Started with Superset
+  - [Superset in 2 Minutes using Docker Compose](https://superset.apache.org/docs/installation/docker-compose#installing-superset-locally-using-docker-compose)
+  - [Installing Database Drivers](https://superset.apache.org/docs/configuration/databases#installing-database-drivers)
+  - [Building New Database Connectors](https://preset.io/blog/building-database-connector/)
+  - [Create Your First Dashboard](https://superset.apache.org/docs/using-superset/creating-your-first-dashboard/)
+  - [Comprehensive Tutorial for Contributing Code to Apache Superset
+    ](https://preset.io/blog/tutorial-contributing-code-to-apache-superset/)
+- [Resources to master Superset by Preset](https://preset.io/resources/)
+
+- Deploying Superset
+
+  - [Official Docker image](https://hub.docker.com/r/apache/superset)
+  - [Helm Chart](https://github.com/apache/superset/tree/master/helm/superset)
+
+- Recordings of Past [Superset Community Events](https://preset.io/events)
+
+  - [Mixed Time Series Charts](https://preset.io/events/mixed-time-series-visualization-in-superset-workshop/)
+  - [How the Bing Team Customized Superset for the Internal Self-Serve Data & Analytics Platform](https://preset.io/events/how-the-bing-team-heavily-customized-superset-for-their-internal-data/)
+  - [Live Demo: Visualizing MongoDB and Pinot Data using Trino](https://preset.io/events/2021-04-13-visualizing-mongodb-and-pinot-data-using-trino/)
+  - [Introduction to the Superset API](https://preset.io/events/introduction-to-the-superset-api/)
+  - [Building a Database Connector for Superset](https://preset.io/events/2021-02-16-building-a-database-connector-for-superset/)
+
+- Visualizations
+
+  - [Creating Viz Plugins](https://superset.apache.org/docs/contributing/creating-viz-plugins/)
+  - [Managing and Deploying Custom Viz Plugins](https://medium.com/nmc-techblog/apache-superset-manage-custom-viz-plugins-in-production-9fde1a708e55)
+  - [Why Apache Superset is Betting on Apache ECharts](https://preset.io/blog/2021-4-1-why-echarts/)
+
+- [Superset API](https://superset.apache.org/docs/rest-api)
+
+## Repo Activity
+
+<a href="https://next.ossinsight.io/widgets/official/compose-last-28-days-stats?repo_id=39464018" target="_blank" align="center">
+  <picture>
+    <source media="(prefers-color-scheme: dark)" srcset="https://next.ossinsight.io/widgets/official/compose-last-28-days-stats/thumbnail.png?repo_id=39464018&image_size=auto&color_scheme=dark" width="655" height="auto" />
+    <img alt="Performance Stats of apache/superset - Last 28 days" src="https://next.ossinsight.io/widgets/official/compose-last-28-days-stats/thumbnail.png?repo_id=39464018&image_size=auto&color_scheme=light" width="655" height="auto" />
+  </picture>
+</a>
+
+<!-- Made with [OSS Insight](https://ossinsight.io/) -->
+
+<!-- telemetry/analytics pixel: -->
+<img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=bc1c90cd-bc04-4e11-8c7b-289fb2839492" />

docs/versioned_docs/version-6.0.0/quickstart.mdx

@@ -0,0 +1,82 @@
+---
+title: Quickstart
+hide_title: false
+sidebar_position: 2
+---
+
+**Ready to try Apache Superset?** This quickstart guide will help you
+get up and running on your local machine in **3 simple steps**. Note that
+it assumes that you have [Docker](https://www.docker.com),
+[Docker Compose](https://docs.docker.com/compose/), and
+[Git](https://git-scm.com/) installed.
+
+:::caution
+Although we recommend using `Docker Compose` for a quick start in a sandbox-type
+environment and for other development-type use cases, **we
+do not recommend this setup for production**. For this purpose please
+refer to our
+[Installing on Kubernetes](/docs/installation/kubernetes/)
+page.
+:::
+
+### 1. Get Superset
+
+```bash
+git clone https://github.com/apache/superset
+```
+
+### 2. Start the latest official release of Superset
+
+```bash
+# Enter the repository you just cloned
+$ cd superset
+
+# Set the repo to the state associated with the latest official version
+$ git checkout tags/5.0.0
+
+# Fire up Superset using Docker Compose
+$ docker compose -f docker-compose-image-tag.yml up
+```
+
+This may take a moment as Docker Compose will fetch the underlying
+container images and will load up some examples. Once all containers
+are downloaded and the output settles, you're ready to log in.
+
+⚠️ If you get an error message like `validating superset\docker-compose-image-tag.yml: services.superset-worker-beat.env_file.0 must be a string`, you need to update your version of `docker-compose`.
+Note that `docker-compose` is on the path to deprecation and you should now use `docker compose` instead.
+
+### 3. Log into Superset
+
+Now head over to [http://localhost:8088](http://localhost:8088) and log in with the default created account:
+
+```bash
+username: admin
+password: admin
+```
+
+#### 🎉 Congratulations! Superset is now up and running on your machine! 🎉
+
+### Wrapping Up
+
+Once you're done with Superset, you can stop and delete just like any other container environment:
+
+```bash
+docker compose down
+```
+
+:::tip
+You can use the same environment more than once, as Superset will persist data locally. However, make sure to properly stop all
+processes by running Docker Compose `stop` command. By doing so, you can avoid data corruption and/or loss of data.
+:::
+
+## What's next?
+
+From this point on, you can head on to:
+
+- [Create your first Dashboard](/docs/using-superset/creating-your-first-dashboard)
+- [Connect to a Database](/docs/configuration/databases)
+- [Using Docker Compose](/docs/installation/docker-compose)
+- [Configure Superset](/docs/configuration/configuring-superset/)
+- [Installing on Kubernetes](/docs/installation/kubernetes/)
+
+Or just explore our [Documentation](https://superset.apache.org/docs/intro)!

docs/versioned_docs/version-6.0.0/security/cves.mdx

@@ -0,0 +1,130 @@
+---
+title: CVEs fixed by release
+sidebar_position: 2
+---
+#### Version 5.0.0
+
+| CVE            | Title                                                                              | Affected |
+|:---------------|:-----------------------------------------------------------------------------------|---------:|
+| CVE-2025-55673 | Exposure of Sensitive Information to an Unauthorized Actor                         |  < 5.0.0 |
+| CVE-2025-55674 | Improper Neutralization of Special Elements used in an SQL Command                 |  < 5.0.0 |
+| CVE-2025-55675 | Improper Access Control leading to Information Disclosure                          |  < 5.0.0 |
+
+#### Version 4.1.3
+
+| CVE            | Title                                                                              | Affected |
+|:---------------|:-----------------------------------------------------------------------------------|---------:|
+| CVE-2025-55672 | Improper Neutralization of Input During Web Page Generation                        |  < 4.1.3 |
+
+#### Version 4.1.2
+
+| CVE            | Title                                                                              | Affected |
+|:---------------|:-----------------------------------------------------------------------------------|---------:|
+| CVE-2025-27696 | Improper authorization leading to resource ownership takeover                      |  < 4.1.2 |
+| CVE-2025-48912 | Improper authorization bypass on row level security via SQL Injection              |  < 4.1.2 |
+
+#### Version 4.1.0
+
+| CVE            | Title                                                                              | Affected |
+|:---------------|:-----------------------------------------------------------------------------------|---------:|
+| CVE-2024-53947 | Improper SQL authorisation, parse for specific postgres functions                  |  < 4.1.0 |
+| CVE-2024-53948 | Error verbosity exposes metadata in analytics databases                            |  < 4.1.0 |
+| CVE-2024-53949 | Lower privilege users are able to create Role when FAB_ADD_SECURITY_API is enabled |  < 4.1.0 |
+| CVE-2024-55633 | SQLLab Improper readonly query validation allows unauthorized write access         |  < 4.1.0 |
+
+#### Version 4.0.2
+
+| CVE            | Title                       | Affected |
+|:---------------|:----------------------------|---------:|
+| CVE-2024-39887 | Improper SQL authorization  |  < 4.0.1 |
+
+#### Version 3.1.3, 4.0.1
+
+| CVE            | Title                       |                    Affected |
+|:---------------|:----------------------------|----------------------------:|
+| CVE-2024-34693 | Server arbitrary file read  |  < 3.1.3, >= 4.0.0, < 4.0.1 |
+
+#### Version 3.1.2
+
+| CVE            | Title                                                   | Affected |
+|:---------------|:--------------------------------------------------------|---------:|
+| CVE-2024-28148 | Incorrect datasource authorization on explore REST API  |  < 3.1.2 |
+
+#### Version 3.0.4, 3.1.1
+
+| CVE            | Title                                                                        |                    Affected |
+|:---------------|:-----------------------------------------------------------------------------|----------------------------:|
+| CVE-2024-27315 | Improper error handling on alerts                                            |  < 3.0.4, >= 3.1.0, < 3.1.1 |
+| CVE-2024-24773 | Improper validation of SQL statements allows for unauthorized access to data |  < 3.0.4, >= 3.1.0, < 3.1.1 |
+| CVE-2024-24772 | Improper Neutralisation of custom SQL on embedded context                    |  < 3.0.4, >= 3.1.0, < 3.1.1 |
+| CVE-2024-24779 | Improper data authorization when creating a new dataset                      |  < 3.0.4, >= 3.1.0, < 3.1.1 |
+| CVE-2024-26016 | Improper authorization validation on dashboards and charts import            |  < 3.0.4, >= 3.1.0, < 3.1.1 |
+
+#### Version 3.0.3
+
+| CVE            | Title                                         | Affected |
+|:---------------|:----------------------------------------------|---------:|
+| CVE-2023-49657 | Stored XSS in Dashboard Title and Chart Title |  < 3.0.3 |
+
+#### Version 3.0.2, 2.1.3
+
+| CVE            | Title                                                       |                   Affected |
+|:---------------|:------------------------------------------------------------|---------------------------:|
+| CVE-2023-46104 | Allows for uncontrolled resource consumption via a ZIP bomb | < 2.1.3, >= 3.0.0, < 3.0.2 |
+| CVE-2023-49736 | SQL Injection on where_in JINJA macro                       | < 2.1.3, >= 3.0.0, < 3.0.2 |
+| CVE-2023-49734 | Privilege Escalation Vulnerability                          | < 2.1.3, >= 3.0.0, < 3.0.2 |
+
+#### Version 3.0.0
+
+| CVE            | Title                                                                   | Affected |
+|:---------------|:------------------------------------------------------------------------|---------:|
+| CVE-2023-42502 | Open Redirect Vulnerability                                             |  < 3.0.0 |
+| CVE-2023-42505 | Sensitive information disclosure on db connection details               |  < 3.0.0 |
+
+#### Version 2.1.3
+
+| CVE            | Title                                                                   | Affected |
+|:---------------|:------------------------------------------------------------------------|---------:|
+| CVE-2023-42504 | Lack of rate limiting allows for possible denial of service             |  < 2.1.3 |
+
+#### Version 2.1.2
+
+| CVE            | Title                                                                   | Affected |
+|:---------------|:------------------------------------------------------------------------|---------:|
+| CVE-2023-40610 | Privilege escalation with default examples database                     |  < 2.1.2 |
+| CVE-2023-42501 | Unnecessary read permissions within the Gamma role                      |  < 2.1.2 |
+| CVE-2023-43701 | Stored XSS on API endpoint                                              |  < 2.1.2 |
+
+#### Version 2.1.1
+
+| CVE            | Title                                                                   | Affected |
+|:---------------|:------------------------------------------------------------------------|---------:|
+| CVE-2023-36387 | Improper API permission for low privilege users                         |  < 2.1.1 |
+| CVE-2023-36388 | Improper API permission for low privilege users allows for SSRF         |  < 2.1.1 |
+| CVE-2023-27523 | Improper data permission validation on Jinja templated queries          |  < 2.1.1 |
+| CVE-2023-27526 | Improper Authorization check on import charts                           |  < 2.1.1 |
+| CVE-2023-39264 | Stack traces enabled by default                                         |  < 2.1.1 |
+| CVE-2023-39265 | Possible Unauthorized Registration of SQLite Database Connections       |  < 2.1.1 |
+| CVE-2023-37941 | Metadata db write access can lead to remote code execution              |  < 2.1.1 |
+| CVE-2023-32672 | SQL parser edge case bypasses data access authorization                 |  < 2.1.1 |
+
+#### Version 2.1.0
+
+| CVE            | Title                                                                   | Affected |
+|:---------------|:------------------------------------------------------------------------|---------:|
+| CVE-2023-25504 | Possible SSRF on import datasets                                        |  < 2.1.0 |
+| CVE-2023-27524 | Session validation vulnerability when using provided default SECRET_KEY |  < 2.1.0 |
+| CVE-2023-27525 | Incorrect default permissions for Gamma role                            |  < 2.1.0 |
+| CVE-2023-30776 | Database connection password leak                                       |  < 2.1.0 |
+
+#### Version 2.0.1
+
+| CVE            | Title                                                       |          Affected  |
+|:---------------|:------------------------------------------------------------|------------------: |
+| CVE-2022-41703 | SQL injection vulnerability in adhoc clauses                | < 2.0.1 or < 1.5.2 |
+| CVE-2022-43717 | Cross-Site Scripting on dashboards                          | < 2.0.1 or < 1.5.2 |
+| CVE-2022-43718 | Cross-Site Scripting vulnerability on upload forms          | < 2.0.1 or < 1.5.2 |
+| CVE-2022-43719 | Cross Site Request Forgery (CSRF) on accept, request access | < 2.0.1 or < 1.5.2 |
+| CVE-2022-43720 | Improper rendering of user input                            | < 2.0.1 or < 1.5.2 |
+| CVE-2022-43721 | Open Redirect Vulnerability                                 | < 2.0.1 or < 1.5.2 |
+| CVE-2022-45438 | Dashboard metadata information leak                         | < 2.0.1 or < 1.5.2 |

docs/versioned_docs/version-6.0.0/security/security.mdx

@@ -0,0 +1,362 @@
+---
+title: Security Configurations
+sidebar_position: 1
+---
+
+Authentication and authorization in Superset is handled by Flask AppBuilder (FAB), an application development framework
+built on top of Flask. FAB provides authentication, user management, permissions and roles.
+Please read its [Security documentation](https://flask-appbuilder.readthedocs.io/en/latest/security.html).
+
+### Provided Roles
+
+Superset ships with a set of roles that are handled by Superset itself. You can assume
+that these roles will stay up-to-date as Superset evolves (and as you update Superset versions).
+
+Even though **Admin** users have the ability, we don't recommend altering the
+permissions associated with each role (e.g. by removing or adding permissions to them). The permissions
+associated with each role will be re-synchronized to their original values when you run
+the **superset init** command (often done between Superset versions).
+
+A table with the permissions for these roles can be found at [/RESOURCES/STANDARD_ROLES.md](https://github.com/apache/superset/blob/master/RESOURCES/STANDARD_ROLES.md).
+
+### Admin
+
+Admins have all possible rights, including granting or revoking rights from other
+users and altering other people’s slices and dashboards.
+
+### Alpha
+
+Alpha users have access to all data sources, but they cannot grant or revoke access
+from other users. They are also limited to altering the objects that they own. Alpha users can add and alter data sources.
+
+### Gamma
+
+Gamma users have limited access. They can only consume data coming from data sources
+they have been given access to through another complementary role. They only have access to
+view the slices and dashboards made from data sources that they have access to. Currently Gamma
+users are not able to alter or add data sources. We assume that they are mostly content consumers, though they can create slices and dashboards.
+
+Also note that when Gamma users look at the dashboards and slices list view, they will
+only see the objects that they have access to.
+
+### sql_lab
+
+The **sql_lab** role grants access to SQL Lab. Note that while **Admin** users have access
+to all databases by default, both **Alpha** and **Gamma** users need to be given access on a per database basis.
+
+### Public
+
+To allow logged-out users to access some Superset features, you can use the `PUBLIC_ROLE_LIKE` config setting and assign it to another role whose permissions you want passed to this role.
+
+For example, by setting `PUBLIC_ROLE_LIKE = "Gamma"` in your `superset_config.py` file, you grant
+public role the same set of permissions as for the **Gamma** role. This is useful if one
+wants to enable anonymous users to view dashboards. Explicit grant on specific datasets is
+still required, meaning that you need to edit the **Public** role and add the public data sources to the role manually.
+
+### Managing Data Source Access for Gamma Roles
+
+Here’s how to provide users access to only specific datasets. First make sure the users with
+limited access have [only] the Gamma role assigned to them. Second, create a new role (Menu -> Security -> List Roles) and click the + sign.
+
+This new window allows you to give this new role a name, attribute it to users and select the
+tables in the **Permissions** dropdown. To select the data sources you want to associate with this role, simply click on the dropdown and use the typeahead to search for your table names.
+
+You can then confirm with users assigned to the **Gamma** role that they see the
+objects (dashboards and slices) associated with the tables you just extended them.
+
+### SQL Execution Security Considerations
+
+Apache Superset includes features designed to provide safeguards when interacting with connected databases, such as the `DISALLOWED_SQL_FUNCTIONS` configuration setting. This aims to prevent the execution of potentially harmful database functions or system variables directly from Superset interfaces like SQL Lab.
+
+However, it is crucial to understand the following:
+
+**Superset is Not a Database Firewall**: Superset's built-in checks, like `DISALLOWED_SQL_FUNCTIONS`, provide a layer of protection but cannot guarantee complete security against all database-level threats or advanced bypass techniques (like specific comment injection methods). They should be viewed as a supplement to, not a replacement for, robust database security.
+
+**Configuration is Key**: The effectiveness of Superset's safeguards heavily depends on proper configuration by the Superset administrator. This includes maintaining the `DISALLOWED_SQL_FUNCTIONS` list, carefully managing feature flags (like `ENABLE_TEMPLATE_PROCESSING`), and configuring other security settings appropriately.
+
+**Database Security is Paramount**: The ultimate responsibility for securing database access, controlling permissions, and preventing unauthorized function execution lies with the database administrators (DBAs) and security teams managing the underlying database instance.
+
+**Recommended Database Practices**: We strongly recommend implementing security best practices at the database level, including:
+* **Least Privilege**: Connecting Superset using dedicated database user accounts with the minimum permissions required for Superset's operation (typically read-only access to necessary schemas/tables).
+* **Database Roles & Permissions**: Utilizing database-native roles and permissions to restrict access to sensitive functions, system variables (like `@@hostname`), schemas, or tables.
+* **Network Security**: Employing network-level controls like database firewalls or proxies to restrict connections.
+* **Auditing**: Enabling database-level auditing to monitor executed queries and access patterns.
+
+By combining Superset's configurable safeguards with strong database-level security practices, you can achieve a more robust and layered security posture.
+
+### REST API for user & role management
+
+Flask-AppBuilder supports a REST API for user CRUD,
+but this feature is in beta and is not enabled by default in Superset.
+To enable this feature, set the following in your Superset configuration:
+
+```python
+FAB_ADD_SECURITY_API = True
+```
+
+Once configured, the documentation for additional "Security" endpoints will be visible in Swagger for you to explore.
+
+### Customizing Permissions
+
+The permissions exposed by FAB are very granular and allow for a great level of
+customization. FAB creates many permissions automatically for each model that is
+created (can_add, can_delete, can_show, can_edit, …) as well as for each view.
+On top of that, Superset can expose more granular permissions like **all_datasource_access**.
+
+**We do not recommend altering the 3 base roles as there are a set of assumptions that
+Superset is built upon**. It is possible though for you to create your own roles, and union them to existing ones.
+
+### Permissions
+
+Roles are composed of a set of permissions, and Superset has many categories of
+permissions. Here are the different categories of permissions:
+
+- Model & Action: models are entities like Dashboard, Slice, or User. Each model has
+  a fixed set of permissions, like **can_edit**, **can_show**, **can_delete**, **can_list**, **can_add**,
+  and so on. For example, you can allow a user to delete dashboards by adding **can_delete** on
+  Dashboard entity to a role and granting this user that role.
+- Views: views are individual web pages, like the Explore view or the SQL Lab view.
+  When granted to a user, they will see that view in its menu items, and be able to load that page.
+- Data source: For each data source, a permission is created. If the user does not have the
+  `all_datasource_access permission` granted, the user will only be able to see Slices or explore the data sources that are granted to them
+- Database: Granting access to a database allows for the user to access all
+  data sources within that database, and will enable the user to query that
+  database in SQL Lab, provided that the SQL Lab specific permission have been granted to the user
+
+### Restricting Access to a Subset of Data Sources
+
+We recommend giving a user the **Gamma** role plus any other roles that would add
+access to specific data sources. We recommend that you create individual roles for
+each access profile. For example, the users on the Finance team might have access to a set of
+databases and data sources; these permissions can be consolidated in a single role.
+Users with this profile then need to be assigned the **Gamma** role as a foundation to
+the models and views they can access, and that Finance role that is a collection of permissions to data objects.
+
+A user can have multiple roles associated with them. For example, an executive on the Finance
+team could be granted **Gamma**, **Finance**, and the **Executive** roles. The **Executive**
+role could provide access to a set of data sources and dashboards made available only to executives.
+In the **Dashboards** view, a user can only see the ones they have access to
+based on the roles and permissions that were attributed.
+
+### Row Level Security
+
+Using Row Level Security filters (under the **Security** menu) you can create filters
+that are assigned to a particular table, as well as a set of roles.
+If you want members of the Finance team to only have access to
+rows where `department = "finance"`, you could:
+
+- Create a Row Level Security filter with that clause (`department = "finance"`)
+- Then assign the clause to the **Finance** role and the table it applies to
+
+The **clause** field, which can contain arbitrary text, is then added to the generated
+SQL statement’s WHERE clause. So you could even do something like create a filter
+for the last 30 days and apply it to a specific role, with a clause
+like `date_field > DATE_SUB(NOW(), INTERVAL 30 DAY)`. It can also support
+multiple conditions: `client_id = 6` AND `advertiser="foo"`, etc.
+
+All relevant Row level security filters will be combined together (under the hood,
+the different SQL clauses are combined using AND statements). This means it's
+possible to create a situation where two roles conflict in such a way as to limit a table subset to empty.
+
+For example, the filters `client_id=4` and `client_id=5`, applied to a role,
+will result in users of that role having `client_id=4` AND `client_id=5`
+added to their query, which can never be true.
+
+### User Sessions
+
+Superset uses [Flask](https://pypi.org/project/Flask/)
+and [Flask-Login](https://pypi.org/project/Flask-Login/) for user session management.
+
+Session cookies are used to maintain session info and user state between requests,
+although they do not contain personal user information they serve the purpose of identifying
+a user session on the server side.
+The session cookie is encrypted with the application `SECRET_KEY` and cannot be read by the client.
+So it's very important to keep the `SECRET_KEY` secret and set to a secure unique complex random value.
+
+Flask and Flask-Login offer a number of configuration options to control session behavior.
+
+- Relevant Flask settings:
+
+`SESSION_COOKIE_HTTPONLY`: (default: `False`): Controls if cookies should be set with the `HttpOnly` flag.
+
+`SESSION_COOKIE_SECURE`: (default: `False`) Browsers will only send cookies with requests over
+HTTPS if the cookie is marked “secure”. The application must be served over HTTPS for this to make sense.
+
+`SESSION_COOKIE_SAMESITE`: (default: "Lax") Prevents the browser from sending this cookie along with cross-site requests.
+
+`PERMANENT_SESSION_LIFETIME`: (default: "31 days") The lifetime of a permanent session as a `datetime.timedelta` object.
+
+#### Switching to server side sessions
+
+Server side sessions offer benefits over client side sessions on security and performance.
+By enabling server side sessions, the session data is stored server side and only a session ID
+is sent to the client. When a user logs in, a session is created server side and the session ID
+is sent to the client in a cookie. The client will send the session ID with each request and the
+server will use it to retrieve the session data.
+On logout, the session is destroyed server side and the session cookie is deleted on the client side.
+This reduces the risk for replay attacks and session hijacking.
+
+Superset uses [Flask-Session](https://flask-session.readthedocs.io/en/latest/) to manage server side sessions.
+To enable this extension you have to set:
+
+``` python
+SESSION_SERVER_SIDE = True
+```
+
+Flask-Session offers multiple backend session interfaces for Flask, here's an example for Redis:
+
+``` python
+from redis import Redis
+
+SESSION_TYPE = "redis"
+SESSION_REDIS = Redis(host="redis", port=6379, db=0)
+# sign the session cookie sid
+SESSION_USE_SIGNER = True
+```
+
+### Content Security Policy (CSP)
+
+Superset uses the [Talisman](https://pypi.org/project/flask-talisman/) extension to enable implementation of a
+[Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP), an added
+layer of security that helps to detect and mitigate certain types of attacks, including
+Cross-Site Scripting (XSS) and data injection attacks.
+
+A CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can
+occur by specifying the domains that the browser should consider to be valid sources of executable scripts.
+A CSP-compatible browser will then only execute scripts loaded in source files received from those allowed domains,
+ignoring all other scripts (including inline scripts and event-handling HTML attributes).
+
+A policy is described using a series of policy directives, each of which describes the policy for
+a certain resource type or policy area. You can check possible directives
+[here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy).
+
+It's extremely important to correctly configure a Content Security Policy when deploying Superset to
+prevent many types of attacks. Superset provides two variables in `config.py` for deploying a CSP:
+
+- `TALISMAN_ENABLED` defaults to `True`; set this to `False` in order to disable CSP
+- `TALISMAN_CONFIG` holds the actual the policy definition (*see example below*) as well as any
+other arguments to be passed to Talisman.
+
+When running in production mode, Superset will check at startup for the presence
+of a CSP. If one is not found, it will issue a warning with the security risks. For environments
+where CSP policies are defined outside of Superset using other software, administrators can disable
+this warning using the `CONTENT_SECURITY_POLICY_WARNING` key in `config.py`.
+
+#### CSP Requirements
+
+- Superset needs the `style-src unsafe-inline` CSP directive in order to operate.
+
+  ```
+  style-src 'self' 'unsafe-inline'
+  ```
+
+- Only scripts marked with a [nonce](https://content-security-policy.com/nonce/) can be loaded and executed.
+Nonce is a random string automatically generated by Talisman on each page load.
+You can get current nonce value by calling jinja macro `csp_nonce()`.
+
+  ```html
+  <script nonce="{{ csp_nonce() }}">
+  /* my script */
+  </script>
+  ```
+
+- Some dashboards load images using data URIs and require `data:` in their `img-src`
+
+  ```
+  img-src 'self' data:
+  ```
+
+- MapBox charts use workers and need to connect to MapBox servers in addition to the Superset origin
+
+  ```
+  worker-src 'self' blob:
+  connect-src 'self' https://api.mapbox.com https://events.mapbox.com
+  ```
+
+- Cartodiagram charts request map data (image and json) from external resources that can be edited by users,
+and therefore either require a list of allowed domains to request from or a wildcard (`'*'`) for `img-src` and `connect-src`.
+
+- Other CSP directives default to `'self'` to limit content to the same origin as the Superset server.
+
+In order to adjust provided CSP configuration to your needs, follow the instructions and examples provided in
+[Content Security Policy Reference](https://content-security-policy.com/)
+
+#### Other Talisman security considerations
+
+Setting `TALISMAN_ENABLED = True` will invoke Talisman's protection with its default arguments,
+of which `content_security_policy` is only one. Those can be found in the
+[Talisman documentation](https://pypi.org/project/flask-talisman/) under *Options*.
+These generally improve security, but administrators should be aware of their existence.
+
+In particular, the option of `force_https = True` (`False` by default) may break Superset's Alerts & Reports
+if workers are configured to access charts via a `WEBDRIVER_BASEURL` beginning
+with `http://`.  As long as a Superset deployment enforces https upstream, e.g.,
+through a load balancer or application gateway, it should be acceptable to keep this
+option disabled. Otherwise, you may want to enable `force_https` like this:
+
+```python
+TALISMAN_CONFIG = {
+    "force_https": True,
+    "content_security_policy": { ...
+```
+
+#### Configuring Talisman in Superset
+
+Talisman settings in Superset can be modified using superset_config.py. If you need to adjust security policies, you can override the default configuration.
+
+Example: Overriding Talisman Configuration in superset_config.py for loading images form s3 or other external sources.
+
+```python
+TALISMAN_CONFIG = {
+    "content_security_policy": {
+        "base-uri": ["'self'"],
+        "default-src": ["'self'"],
+        "img-src": [
+            "'self'",
+            "blob:",
+            "data:",
+            "https://apachesuperset.gateway.scarf.sh",
+            "https://static.scarf.sh/",
+            # "https://cdn.brandfolder.io", # Uncomment when SLACK_ENABLE_AVATARS is True  # noqa: E501
+            "ows.terrestris.de",
+            "aws.s3.com", # Add Your Bucket or external data source
+        ],
+        "worker-src": ["'self'", "blob:"],
+        "connect-src": [
+            "'self'",
+            "https://api.mapbox.com",
+            "https://events.mapbox.com",
+        ],
+        "object-src": "'none'",
+        "style-src": [
+            "'self'",
+            "'unsafe-inline'",
+        ],
+        "script-src": ["'self'", "'strict-dynamic'"],
+    },
+    "content_security_policy_nonce_in": ["script-src"],
+    "force_https": False,
+    "session_cookie_secure": False,
+}
+```
+
+For more information on setting up Talisman, please refer to
+https://superset.apache.org/docs/configuration/networking-settings/#changing-flask-talisman-csp.
+
+### Reporting Security Vulnerabilities
+
+Apache Software Foundation takes a rigorous standpoint in annihilating the security issues in its
+software projects. Apache Superset is highly sensitive and forthcoming to issues pertaining to its
+features and functionality.
+
+If you have apprehensions regarding Superset security or you discover vulnerability or potential
+threat, don’t hesitate to get in touch with the Apache Security Team by dropping a mail at
+security@apache.org. In the mail, specify the project name Superset with the description of the
+issue or potential threat. You are also urged to recommend the way to reproduce and replicate the
+issue. The security team and the Superset community will get back to you after assessing and
+analysing the findings.
+
+PLEASE PAY ATTENTION to report the security issue on the security email before disclosing it on
+public domain. The ASF Security Team maintains a page with the description of how vulnerabilities
+and potential threats are handled, check [their web page](https://apache.org/security/committers.html)
+for more details.

docs/versioned_docs/version-6.0.0/using-superset/creating-your-first-dashboard.mdx

@@ -0,0 +1,231 @@
+---
+title: Creating Your First Dashboard
+hide_title: true
+sidebar_position: 1
+version: 1
+---
+
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+## Creating Your First Dashboard
+
+This section is focused on documentation for end-users who will be using Superset
+for the data analysis and exploration workflow
+ (data analysts, business analysts, data
+scientists, etc).
+
+:::tip
+In addition to this site, [Preset.io](http://preset.io/) maintains an updated set of end-user
+documentation at [docs.preset.io](https://docs.preset.io/).
+:::
+
+This tutorial targets someone who wants to create charts and dashboards in Superset. We’ll show you
+how to connect Superset to a new database and configure a table in that database for analysis.
+You’ll also explore the data you’ve exposed and add a visualization to a dashboard so that you get a
+feel for the end-to-end user experience.
+
+### Connecting to a new database
+
+Superset itself doesn't have a storage layer to store your data but instead pairs with
+your existing SQL-speaking database or data store.
+
+First things first, we need to add the connection credentials to your database to be able
+to query and visualize data from it. If you're using Superset locally via
+[Docker compose](/docs/installation/docker-compose), you can
+skip this step because a Postgres database, named **examples**, is included and
+pre-configured in Superset for you.
+
+Under the **+** menu in the top right, select Data, and then the _Connect Database_ option:
+
+<img src={useBaseUrl("/img/tutorial/tutorial_01_add_database_connection.png")} width="600" />{" "} <br/><br/>
+
+Then select your database type in the resulting modal:
+
+<img src={useBaseUrl("/img/tutorial/tutorial_02_select_database.png" )} width="600" />{" "} <br/><br/>
+
+Once you've selected a database, you can configure a number of advanced options in this window,
+or for the purposes of this walkthrough, you can click the link below all these fields:
+
+<img src={useBaseUrl("/img/tutorial/tutorial_03a_database_connection_string_link.png" )} width="600" />{" "} <br/><br/>
+
+Please note, if you are trying to connect to another locally running database (whether on host or another container), and you get the message `The port is closed.`, then you need to adjust the HOST to `host.docker.internal`
+
+Once you've clicked that link you only need to specify two things (the database name and SQLAlchemy URI):
+
+<img src={useBaseUrl("/img/tutorial/tutorial_03b_connection_string_details.png" )} width="600" />{" "} <br/><br/>
+
+As noted in the text below the form, you should refer to the SQLAlchemy documentation on
+[creating new connection URIs](https://docs.sqlalchemy.org/en/12/core/engines.html#database-urls)
+for your target database.
+
+Click the **Test Connection** button to confirm things work end to end. If the connection looks good, save the configuration
+by clicking the **Connect** button in the bottom right corner of the modal window:
+
+Congratulations, you've just added a new data source in Superset!
+
+### Registering a new table
+
+Now that you’ve configured a data source, you can select specific tables (called **Datasets** in Superset)
+that you want exposed in Superset for querying.
+
+Navigate to **Data ‣ Datasets** and select the **+ Dataset** button in the top right corner.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_08_sources_tables.png" )} />
+
+A modal window should pop up in front of you. Select your **Database**,
+**Schema**, and **Table** using the drop downs that appear. In the following example,
+we register the **cleaned_sales_data** table from the **examples** database.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_09_add_new_table.png" )} />
+
+To finish, click the **Add** button in the bottom right corner. You should now see your dataset in the list of datasets.
+
+### Customizing column properties
+
+Now that you've registered your dataset, you can configure column properties
+ for how the column should be treated in the Explore workflow:
+
+- Is the column temporal? (should it be used for slicing & dicing in time series charts?)
+- Should the column be filterable?
+- Is the column dimensional?
+- If it's a datetime column, how should Superset parse
+the datetime format? (using the [ISO-8601 string pattern](https://en.wikipedia.org/wiki/ISO_8601))
+
+<img src={useBaseUrl("/img/tutorial/tutorial_column_properties.png" )} />
+
+### Superset semantic layer
+
+Superset has a thin semantic layer that adds many quality of life improvements for analysts.
+The Superset semantic layer can store 2 types of computed data:
+
+1. Virtual metrics: you can write SQL queries that aggregate values
+from multiple column (e.g. `SUM(recovered) / SUM(confirmed)`) and make them
+available as columns for (e.g. `recovery_rate`) visualization in Explore.
+Aggregate functions are allowed and encouraged for metrics.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_sql_metric.png" )} />
+
+You can also certify metrics if you'd like for your team in this view.
+
+1. Virtual calculated columns: you can write SQL queries that
+customize the appearance and behavior
+of a specific column (e.g. `CAST(recovery_rate as float)`).
+Aggregate functions aren't allowed in calculated columns.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_calculated_column.png" )} />
+
+### Creating charts in Explore view
+
+Superset has 2 main interfaces for exploring data:
+
+- **Explore**: no-code viz builder. Select your dataset, select the chart,
+customize the appearance, and publish.
+- **SQL Lab**: SQL IDE for cleaning, joining, and preparing data for Explore workflow
+
+We'll focus on the Explore view for creating charts right now.
+To start the Explore workflow from the **Datasets** tab, start by clicking the name
+of the dataset that will be powering your chart.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_launch_explore.png" )} /><br/><br/>
+
+You're now presented with a powerful workflow for exploring data and iterating on charts.
+
+- The **Dataset** view on the left-hand side has a list of columns and metrics,
+scoped to the current dataset you selected.
+- The **Data** preview below the chart area also gives you helpful data context.
+- Using the **Data** tab and **Customize** tabs, you can change the visualization type,
+select the temporal column, select the metric to group by, and customize
+the aesthetics of the chart.
+
+As you customize your chart using drop-down menus, make sure to click the **Run** button
+to get visual feedback.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_explore_run.jpg" )} />
+
+In the following screenshot, we craft a grouped Time-series Bar Chart to visualize
+our quarterly sales data by product line just by clicking options in drop-down menus.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_explore_settings.jpg" )} />
+
+### Creating a slice and dashboard
+
+To save your chart, first click the **Save** button. You can either:
+
+- Save your chart and add it to an existing dashboard
+- Save your chart and add it to a new dashboard
+
+In the following screenshot, we save the chart to a new "Superset Duper Sales Dashboard":
+
+<img src={useBaseUrl("/img/tutorial/tutorial_save_slice.png" )} />
+
+To publish, click **Save and goto Dashboard**.
+
+Behind the scenes, Superset will create a slice and store all the information needed
+to create your chart in its thin data layer
+ (the query, chart type, options selected, name, etc).
+
+ <img src={useBaseUrl("/img/tutorial/tutorial_first_dashboard.png" )} style={{width: "100%", maxWidth: "500px"}} />
+
+ To resize the chart, start by clicking the Edit Dashboard button in the top right corner.
+
+ <img src={useBaseUrl("/img/tutorial/tutorial_edit_button.png" )} width="300" />
+
+Then, click and drag the bottom right corner of the chart until the chart layout snaps
+into a position you like onto the underlying grid.
+
+ <img src={useBaseUrl("/img/tutorial/tutorial_chart_resize.png" )} style={{width: "100%", maxWidth: "500px"}} />
+
+ Click **Save** to persist the changes.
+
+Congrats! You’ve successfully linked, analyzed, and visualized data in Superset. There are a wealth
+of other table configuration and visualization options, so please start exploring and creating
+slices and dashboards of your own.
+
+### Manage access to Dashboards
+
+Access to dashboards is managed via owners (users that have edit permissions to the dashboard).
+
+Non-owner users access can be managed in two different ways. The dashboard needs to be published to be visible to other users.
+
+1. Dataset permissions - if you add to the relevant role permissions to datasets it automatically grants implicit access to all dashboards that uses those permitted datasets.
+2. Dashboard roles - if you enable [**DASHBOARD_RBAC** feature flag](/docs/configuration/configuring-superset#feature-flags) then you will be able to manage which roles can access the dashboard
+   - Granting a role access to a dashboard will bypass dataset level checks. Having dashboard access implicitly grants read access to all the featured charts in the dashboard, and thereby also all the associated datasets.
+   - If no roles are specified for a dashboard, regular **Dataset permissions** will apply.
+
+<img src={useBaseUrl("/img/tutorial/tutorial_dashboard_access.png" )} />
+
+### Publishing a Dashboard
+
+If you would like to make your dashboard available to other users, click on the `Draft` button next to the
+title of your dashboard.
+
+<img src={useBaseUrl("/img/tutorial/publish_button_dashboard.png" )} />
+
+:::warning
+Draft dashboards are only visible to the dashboard owners and admins. Published dashboards are visible to all users with access to the underlying datasets or if RBAC is enabled, to the roles that have been granted access to the dashboard.
+:::
+
+### Mark a Dashboard as Favorite
+
+You can mark a dashboard as a favorite by clicking on the star icon next to the title of your dashboard. This makes it easier to find it in the list of dashboards or on the home page.
+
+### Customizing dashboard
+
+The following URL parameters can be used to modify how the dashboard is rendered:
+
+- `standalone`:
+  - `0` (default): dashboard is displayed normally
+  - `1`: Top Navigation is hidden
+  - `2`: Top Navigation + title is hidden
+  - `3`: Top Navigation + title + top level tabs are hidden
+- `show_filters`:
+  - `0`: render dashboard without Filter Bar
+  - `1` (default): render dashboard with Filter Bar if native filters are enabled
+- `expand_filters`:
+  - (default): render dashboard with Filter Bar expanded if there are native filters
+  - `0`: render dashboard with Filter Bar collapsed
+  - `1`: render dashboard with Filter Bar expanded
+
+For example, when running the local development build, the following will disable the
+Top Nav and remove the Filter Bar:
+`http://localhost:8088/superset/dashboard/my-dashboard/?standalone=1&show_filters=0`