Merge branch 'master' into feat/migrate-from-prettier-to-oxfmt

docs/admin_docs/security/security.mdx

@@ -250,6 +250,51 @@ This feature is particularly useful for:
 - Granting access to dashboards without exposing the underlying datasets for other uses
 - Creating dashboard-specific access patterns that don't align with dataset permissions
 
+#### Assigning the creator's groups automatically
+
+```python
+FEATURE_FLAGS = {
+    "ENABLE_VIEWERS": True,
+    "ASSIGN_CREATOR_GROUPS_AS_VIEWERS": True,
+}
+```
+
+This requires `ENABLE_VIEWERS` — it has no effect on its own, since it works by populating the
+`viewers` relationship that `ENABLE_VIEWERS` governs.
+
+With this enabled, a newly created dashboard or chart is shared read-only with every group its
+creator belongs to, unless the create payload names viewers explicitly. It applies to every path
+that creates an asset: the REST API, `/dashboard/new/`, save-as from Explore, dashboard copy,
+the import commands, and the MCP tools. Datasets are unaffected, as they have editors but no
+viewers.
+
+For dashboards, viewer access additionally requires the dashboard to be **published** — the same
+rule that governs every dashboard viewer. Until a new dashboard is published its creator's groups
+see nothing, and because it now has viewers the dataset-based fallback no longer applies to it
+either; group members gain access only once it is published. Charts have no such publish gate, so a
+new chart's viewer grant takes effect immediately. Note, though, that the viewer relationship
+governs access to the chart itself; rendering its **data** still runs the normal datasource
+permission check unless `VIEWER_PROMISCUOUS_MODE` is enabled — a group member without access to the
+underlying dataset can open the chart but won't load its data.
+
+Note that this **narrows** access rather than widening it. Because an asset with no viewers falls
+back to dataset-based access, giving new assets a viewer makes that fallback unreachable for them:
+a colleague who could previously open a new dashboard by virtue of dataset access can no longer do
+so unless they share one of the creator's groups. Existing assets are untouched — only assets
+created after the feature flag is enabled are affected.
+
+The same narrowing affects background execution as a fixed identity. Alerts, reports, and
+thumbnails that run as a `FixedExecutor` service account (via `ALERT_REPORTS_EXECUTE_AS` or
+`THUMBNAIL_EXECUTE_AS`) reach a chart or dashboard through the dataset fallback when that account
+is neither an editor nor a viewer. Once a new asset is scoped to the creator's groups that
+fallback is gone, so rendering fails `raise_for_access` unless the executor account is an admin,
+an editor, or shares one of those groups. If a fixed executor must render assets it does not own,
+grant it the needed access (make it an admin or add it to the relevant groups) — or leave the
+feature flag off.
+
+The setting assigns groups as *viewers*, not editors, so group members get read-only access and
+cannot modify or delete the asset.
+
 ### 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.