Title: Global Cross-Resource Search with Keyboard Navigation

[iskanderknani2005-oss]

Problem:
Superset today has separate search bars inside each list view — one for Charts, one for Dashboards, one for Datasets, and one for SQL Lab saved queries. If a user remembers the name of something but not where it lives, they must check each section manually. There is no single entry point to find anything across the entire platform. For large organizations with hundreds of dashboards and thousands of charts this becomes a serious productivity problem.

Proposed Solution:
Add a persistent global search bar to the Superset top navigation, triggerable from anywhere in the application using the keyboard shortcut Ctrl+K on Windows or Cmd+K on Mac — the same convention used by Notion, Linear, Figma, and VS Code. Typing in the bar searches across five resource types simultaneously: Dashboards, Charts, Datasets, SQL Lab saved queries, and Database connections. Results appear instantly in a dropdown grouped by resource type. Each result shows the resource name, its type icon, and who last modified it. Arrow keys navigate between results, Enter opens the selected resource, and Escape closes the panel. The search indexes resource names, descriptions, and owner names. Results are filtered by the current user's access permissions so users only see resources they are allowed to open.

What Changes:
Backend → new /api/v1/search?q= endpoint that queries all resource tables in parallel
Backend → permission filtering applied per resource type in the same query
Frontend → global search input in the top nav bar (always visible)
Frontend → keyboard shortcut listener (Ctrl+K / Cmd+K) that focuses the input
Frontend → dropdown results panel with grouped sections and keyboard navigation
Frontend → recently viewed resources shown when the input is focused but empty

Why It Is Not Implemented Yet:
A cross-resource search requires a unified backend endpoint that queries multiple unrelated tables and applies different permission checks per resource type. The current architecture handles each resource type in a completely separate API with no shared search layer.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SIP-007
Title: Collaborative In-Dashboard Chart Comments with Threading

Problem:
Superset dashboards are shared across teams — finance, product, operations — but the platform offers no way for viewers to communicate about the data they are looking at. When someone spots an unusual number on a chart, their only option is to take a screenshot and paste it into Slack or an email, losing all context. There is no in-app way to ask a question about a specific chart, flag a data issue, or leave a note for the next person who opens the dashboard. This makes Superset purely a consumption tool with no collaboration layer.

Proposed Solution:
Add a comment system anchored to individual charts on a dashboard. Any user with at least Viewer access to a dashboard can open a comment panel for any chart by clicking a speech bubble icon that appears on hover. The panel shows existing comments in a threaded list. Users can write a new comment, reply to an existing one, and tag teammates using @username which sends them an in-app notification. Once an issue is resolved the comment thread can be marked as resolved which collapses it but keeps it accessible in a Resolved tab. Dashboard owners can delete any comment. Regular users can only delete their own.

Comment Visibility Rules:
→ A user who cannot access the dashboard cannot see or post comments on it
→ Comments on embedded dashboards are hidden entirely
→ Resolved comments are collapsed but preserved in audit history

What Changes:
Database → new dashboard_chart_comments table: id, dashboard_id, chart_id, user_id, parent_comment_id, body, resolved, created_at
Database → new comment_notifications table for @mention tracking
Backend → new /api/v1/dashboard/{id}/chart/{id}/comments endpoints (GET, POST, PATCH, DELETE)
Backend → notification dispatch on @mention (in-app only, email optional via config)
Frontend → speech bubble icon on chart hover in dashboard view mode
Frontend → comment side panel with thread list and reply composer
Frontend → notification bell in top nav showing unread @mentions

Why It Is Not Implemented Yet:
This requires a new data model, a new API surface, and a real-time or polling notification system — none of which exist in the current codebase. It is a self-contained feature that touches backend, frontend, and infrastructure without modifying any existing chart or dashboard logic.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SIP-008
Title: Independent Mobile Layout Mode for Dashboards

Problem:
Superset dashboards use a single fixed grid layout for all screen sizes. When a dashboard is opened on a phone or tablet, the desktop grid is compressed into the narrow viewport. Charts overlap, text gets truncated, filters become unusable, and scroll behavior breaks. There is no way for a dashboard creator to define how the dashboard should look on a small screen independently from the desktop layout. As Superset is increasingly accessed on mobile devices — especially for executive dashboards and field operations — this gap becomes a significant usability problem.

Proposed Solution:
Add a Mobile Layout mode to the dashboard editor. When a creator switches to Mobile Layout mode, they see a phone-width canvas showing a simplified single-column version of the dashboard. They can drag and drop charts into a different order, resize them for the narrow viewport, and hide charts that do not make sense on mobile such as large data tables. The mobile layout is stored as a separate JSON layout object inside the dashboard's existing metadata structure under a new mobile_layout key. When a user opens the dashboard, Superset detects the viewport width on load. If it falls below a configurable breakpoint (default 768px) the mobile layout is rendered instead of the desktop one. If no mobile layout has been defined the desktop layout is used as a fallback.

Layout Switching Logic:
Desktop viewport (≥768px) → render layout.default
Mobile viewport (<768px) → render layout.mobile if defined, else layout.default
Breakpoint value is configurable per-deployment via MOBILE_LAYOUT_BREAKPOINT_PX

What Changes:
Database → dashboard metadata JSON gains a mobile_layout key (no schema migration needed — stored in existing JSON column)
Backend → dashboard GET response includes both layout.default and layout.mobile
Frontend → Mobile Layout toggle button in the dashboard editor toolbar
Frontend → phone-frame canvas in edit mode when Mobile Layout is active
Frontend → viewport detection on dashboard load to select which layout to render
Frontend → Hide on Mobile toggle per chart component

Why It Is Not Implemented Yet:
The current dashboard renderer is tightly coupled to a single layout object. Supporting two independent layouts requires the renderer to accept a layout parameter at load time rather than always reading from a single source, which is a structural change to how dashboards are initialized.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SIP-009 (NEW)
Title: Scheduled Dashboard Snapshots Delivered as PDF or Image

Problem:
Superset already has an alerts and reports system but it only sends chart-level screenshots. There is no built-in way to schedule a full dashboard to be rendered as a single PDF or image and delivered to a list of recipients on a recurring schedule. Many business teams want a weekly PDF of their KPI dashboard in their inbox every Monday morning without having to log in to Superset. Currently this requires third-party tooling or custom scripting outside of Superset.

Proposed Solution:
Add a Schedule Snapshot option to the dashboard menu. The creator sets a recurrence (daily, weekly, monthly or a custom cron expression), chooses a delivery format (PDF or PNG), and enters a list of recipient email addresses. At the scheduled time Superset renders the full dashboard in a headless browser using the existing screenshot infrastructure, assembles the output into a single file, and delivers it via the configured email backend. The recipient does not need a Superset account to receive the file. A log of past deliveries is accessible from the dashboard settings panel showing the timestamp, recipient list, and delivery status of each run.

What Changes:
Backend → new dashboard_schedules table: id, dashboard_id, cron_expression, format (pdf/png), recipients (JSON array), last_run_at, created_by
Backend → new Celery beat task that reads dashboard_schedules and triggers renders
Backend → extend existing screenshot renderer to support full-dashboard multi-chart capture
Backend → PDF assembly using existing jsPDF dependency already in the project
Frontend → Schedule Snapshot option in the dashboard three-dot menu
Frontend → schedule configuration modal: recurrence picker, format selector, recipient list
Frontend → delivery history table in dashboard settings

Why It Is Not Implemented Yet:
The existing reports system is chart-scoped. Extending it to render and assemble a full multi-chart dashboard as a single PDF requires the renderer to capture the entire dashboard DOM rather than individual chart containers, which is a different rendering path not yet built.