apache · villebro · Jul 8, 2026 · Mar 23, 2026 · Apr 1, 2026 · Apr 1, 2026
diff --git a/UPDATING.md b/UPDATING.md
diff --git a/docs/admin_docs/configuration/alerts-reports.mdx b/docs/admin_docs/configuration/alerts-reports.mdx
@@ -287,8 +287,10 @@ to specify on behalf of which username to render the dashboards. In general, das
 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):
+By default, Alerts and Reports are executed as a physical user represented by the alert/report editors
+(giving priority to the last modifier, then the creator, then the first direct user editor, then a
+deterministic user from editor roles or groups). To use a fixed user account, just change the config
+as follows (`admin` in this example):
 
 ```python
 from superset.tasks.types import FixedExecutor

diff --git a/docs/admin_docs/configuration/cache.mdx b/docs/admin_docs/configuration/cache.mdx
@@ -139,6 +139,10 @@ from superset.tasks.types import FixedExecutor
 THUMBNAIL_EXECUTORS = [FixedExecutor("admin")]
 ```
 
+When using `ExecutorType.EDITOR`, thumbnails are rendered as a physical user represented by
+the dashboard or chart editors. Superset prioritizes the last modifier, then the creator,
+then the first direct user editor, then a deterministic user from editor roles or groups.
+
 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.
 
@@ -179,10 +183,10 @@ WEBDRIVER_BASEURL = "https://superset.company.com"
 
 To control which user account is used for rendering thumbnails and warming up caches, configure
 `THUMBNAIL_EXECUTORS` and `CACHE_WARMUP_EXECUTORS`. Each accepts a list of executor types (which
-resolve to an owner, creator, modifier, or the currently-logged-in user) and/or a `FixedExecutor`
-pinned to a specific username. By default, thumbnails render as the current user
-(`ExecutorType.CURRENT_USER`) and cache warmup runs as the chart/dashboard owner
-(`ExecutorType.OWNER`).
+resolve to an editor, creator, modifier, or the currently-logged-in user) and/or a
+`FixedExecutor` pinned to a specific username. By default, thumbnails render as the current user
+(`ExecutorType.CURRENT_USER`) and cache warmup uses editor-based execution
+(`ExecutorType.EDITOR`) where executor-based cache warmup is used.
 
 To force both to run as a dedicated service account (`admin` in this example):
 

diff --git a/docs/admin_docs/configuration/networking-settings.mdx b/docs/admin_docs/configuration/networking-settings.mdx
@@ -60,9 +60,9 @@ There are two approaches to making dashboards publicly accessible:
 
 **Option 2: Dashboard-level access (selective control)**
 1. Set `PUBLIC_ROLE_LIKE = "Public"` in `superset_config.py`
-2. Add the `'DASHBOARD_RBAC': True` [Feature Flag](/admin-docs/configuration/feature-flags)
-3. Edit each dashboard's properties and add the "Public" role
-4. Only dashboards with the Public role explicitly assigned are visible to anonymous users
+2. Add the `'ENABLE_VIEWERS': True` [Feature Flag](/admin-docs/configuration/feature-flags)
+3. Edit each dashboard's properties and add the "Public" role subject as a viewer
+4. Only published dashboards with the Public role subject explicitly assigned are visible to anonymous users
 
 See the [Public role documentation](/admin-docs/security/#public) for more details.
 

diff --git a/docs/admin_docs/security/securing_superset.mdx b/docs/admin_docs/security/securing_superset.mdx
@@ -176,7 +176,7 @@ https://superset.apache.org/admin-docs/configuration/configuring-superset/#rotat
 
 ### **Appendix C: Secrets Register and Rotation Schedule**
 
-`SUPERSET_SECRET_KEY` is not the only security-critical secret in a Superset deployment. Maintain an inventory of all such secrets, store each in a secrets manager (not in `superset_config.py` or version control), assign an owner, and rotate them on a defined cadence as well as after any suspected compromise.
+`SUPERSET_SECRET_KEY` is not the only security-critical secret in a Superset deployment. Maintain an inventory of all such secrets, store each in a secrets manager (not in `superset_config.py` or version control), assign a responsible maintainer, and rotate them on a defined cadence as well as after any suspected compromise.
 
 | Secret | Purpose | Risk if leaked | Suggested rotation |
 |---|---|---|---|

diff --git a/docs/admin_docs/security/security.mdx b/docs/admin_docs/security/security.mdx
@@ -91,24 +91,24 @@ PUBLIC_ROLE_LIKE = "Public"
 # PUBLIC_ROLE_LIKE = "Gamma"
 ```
 
-If you prefer to manually configure the Public role's permissions (or use `DASHBOARD_RBAC` to
-grant access at the dashboard level), you do not need to set `PUBLIC_ROLE_LIKE`.
+If you prefer to manually configure the Public role's permissions, or use subject-based
+dashboard viewer assignments, you do not need to set `PUBLIC_ROLE_LIKE`.
 
 **Important notes:**
 
-- **Data access is still required:** The Public role only grants UI/API permissions. You must
-  also grant access to specific datasets necessary to view a dashboard. As with other roles,
-  this can be done in two ways:
+- **Data access is still required by default:** The Public role only grants UI/API permissions.
+  You must also grant access to specific datasets necessary to view a dashboard. As with other
+  roles, this can be done in two ways:
 
-  - **Without `DASHBOARD_RBAC`:** Dashboards only appear in the list and are accessible if
-    the user has permission to at least one of their datasets. Grant dataset access by editing
-    the Public role in the Superset UI (Menu → Security → List Roles → Public) and adding the
-    relevant data sources. All published dashboards using those datasets become visible.
+  - **Dataset-based access:** Dashboards only appear in the list and are accessible if the user
+    has permission to at least one of their datasets. Grant dataset access by editing the Public
+    role in the Superset UI (Menu -> Security -> List Roles -> Public) and adding the relevant
+    data sources. All published dashboards using those datasets become visible.
 
-  - **With `DASHBOARD_RBAC` enabled:** Anonymous users will only see dashboards where the
-    "Public" role has been explicitly added in the dashboard's properties. Dataset permissions
-    are not required—DASHBOARD_RBAC handles the cascading permissions check. This provides
-    fine-grained control over which dashboards are publicly visible.
+  - **Subject-based dashboard access:** When `ENABLE_VIEWERS` is enabled, anonymous users can
+    see published dashboards where the "Public" role subject has been explicitly added as a
+    viewer. If `VIEWER_PROMISCUOUS_MODE` is enabled, viewer access can bypass dataset
+    permission checks for dashboard rendering.
 
 - **Role synchronization:** Built-in role permissions (Admin, Alpha, Gamma, sql_lab, and Public
   when `PUBLIC_ROLE_LIKE = "Public"`) are synchronized when you run `superset init`. Any manual
@@ -131,10 +131,76 @@ tables in the **Permissions** dropdown. To select the data sources you want to a
 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.
 
+### Subjects
+
+A **subject** is a unified identity that can be granted access to Superset resources such as
+dashboards, charts, and datasets. Subjects come in three types:
+
+- **User** — an individual Superset user
+- **Group** — a FAB group
+- **Role** — a FAB role (e.g. Alpha, Gamma, or any custom role)
+
+Subjects are used throughout Superset to assign **editors** (who can modify a resource) and
+**viewers** (who can view it). For new resource-specific assignments, Superset defaults to
+**Users** and **Groups** in subject pickers. Groups are the recommended way to grant access to a
+set of people because they represent organizational membership, while roles remain focused on
+capability grants such as "can read dashboards" or "can write charts".
+
+Role subjects are still supported for backwards compatibility with features that previously used
+roles directly, including Row Level Security role assignments and `DASHBOARD_RBAC`. Existing role
+subject assignments continue to be enforced even when roles are not exposed in the default picker
+configuration. However, when an administrator edits a subject list, roles are not available as new
+dropdown values unless that picker has been configured to expose role subjects. Roles are not
+recommended for new subject assignments, because using roles for both permissions and resource
+membership couples two separate concerns.
+
+Administrators can control which subject types are available in pickers with
+`SUBJECTS_RELATED_TYPES`. By default, this setting exposes only users and groups:
+
+```python
+from superset.subjects.types import SubjectType
+
+SUBJECTS_RELATED_TYPES = [
+    SubjectType.USER,
+    SubjectType.GROUP,
+]
+```
+
+Set `SUBJECTS_RELATED_TYPES = None` to expose all subject types, including roles. To expose roles
+only for a specific entity, set that entity's override:
+
+```python
+from superset.subjects.types import SubjectType
+
+SUBJECTS_RELATED_TYPES = [
+    SubjectType.USER,
+    SubjectType.GROUP,
+]
+
+# Leave dashboard, chart, and alert/report overrides unset so they inherit
+# the users + groups default. Expose roles only in the RLS subject picker for
+# compatibility with existing role-based RLS workflows.
+SUBJECTS_RELATED_TYPES_RLS = [
+    SubjectType.USER,
+    SubjectType.GROUP,
+    SubjectType.ROLE,
+]
+```
+
+Available per-entity overrides are:
+
+- `SUBJECTS_RELATED_TYPES_DASHBOARDS` for dashboard editor/viewer pickers
+- `SUBJECTS_RELATED_TYPES_CHARTS` for chart editor/viewer pickers
+- `SUBJECTS_RELATED_TYPES_RLS` for Row Level Security subject pickers
+- `SUBJECTS_RELATED_TYPES_ALERT_REPORTS` for alert/report editor pickers
+
+When an override is set, it replaces `SUBJECTS_RELATED_TYPES` for that picker. When it is `None`,
+the picker inherits the global default.
+
 ### Dashboard Access Control
 
-Access to dashboards is managed via owners (users that have edit permissions to the dashboard).
-Non-owner user access can be managed in two ways. Note that dashboards must be published to be
+Access to dashboards is managed via editors (subjects that have edit permissions to the dashboard).
+Non-editor user access can be managed in two ways. Note that dashboards must be published to be
 visible to other users.
 
 #### Dataset-Based Access (Default)
@@ -146,30 +212,40 @@ to a role (Menu → Security → List Roles).
 This is the simplest approach but provides all-or-nothing access based on dataset permissions—
 if a user has access to a dataset, they can see all published dashboards using that dataset.
 
-#### Dashboard-Level Access (DASHBOARD_RBAC)
+#### Dashboard and Chart-Level Access
 
-For fine-grained control over which dashboards specific roles can access, enable the
-`DASHBOARD_RBAC` feature flag:
+For fine-grained control over which dashboards and charts specific users or groups can access,
+enable subject-based viewers:
 
 ```python
 FEATURE_FLAGS = {
-    "DASHBOARD_RBAC": True,
+    "ENABLE_VIEWERS": True,
 }
 ```
 
-With this enabled, you can assign specific roles to each dashboard in its properties. Users
-will only see dashboards where their role is explicitly added.
+With this enabled, you can assign viewer subjects to each dashboard or chart in its properties.
+Users will see resources where they are assigned directly, or indirectly through a group subject.
+Role subjects can also be enabled for compatibility, but groups are recommended for new viewer
+assignments.
+
+`ENABLE_VIEWERS` can be adopted incrementally. Dashboards and charts with no assigned viewers keep
+the existing implicit dataset-access behavior: users who can access the underlying dataset can still
+see published dashboards that use that dataset and charts backed by that dataset. Assigning one or
+more viewers changes that specific resource to explicit viewer access for non-editors. Removing all
+viewers returns the resource to the dataset-based fallback. Explicit Viewers are the preferred model
+going forward; the implicit fallback may be deprecated and removed in a later major version.
 
 **Important considerations:**
-- Dashboard access **bypasses** dataset-level checks—granting a role access to a dashboard
-  implicitly grants read access to all charts and datasets in that dashboard
-- Dashboards without any assigned roles fall back to dataset-based access
+- Viewer access uses normal dataset checks unless `VIEWER_PROMISCUOUS_MODE` is enabled
+- With `VIEWER_PROMISCUOUS_MODE`, dashboard viewer access can bypass dataset-level checks for
+  charts and datasets in that dashboard
+- Dashboards and charts without assigned viewers fall back to dataset-based access
 - The dashboard must still be published to be visible
 
 This feature is particularly useful for:
 - Making specific dashboards public while keeping others private
 - Granting access to dashboards without exposing the underlying datasets for other uses
-- Creating dashboard-specific access patterns that don't align with dataset ownership
+- Creating dashboard-specific access patterns that don't align with dataset permissions
 
 ### SQL Execution Security Considerations
 
@@ -301,16 +377,16 @@ 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 dataset, as well as a set of roles.
+that are assigned to a particular dataset, as well as a set of subjects.
 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 dataset it applies to
+- Then assign the clause to the **Finance** role subject and the dataset 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
+for the last 30 days and apply it to a specific subject, 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.
 
@@ -321,12 +397,14 @@ RLS clauses also support **Jinja templating** when `ENABLE_TEMPLATE_PROCESSING`
 
 There are two types of RLS filters:
 
-- **Regular** — The filter clause is applied when the querying user belongs to one of the
-  roles assigned to the filter. Use this to restrict what specific roles can see.
-- **Base** — The filter clause is applied to **all** users _except_ those in the assigned
-  roles. Use this to define a default restriction that privileged roles (e.g. Admin) are
-  exempt from. For example, a Base filter with clause `1 = 0` and the Admin role would
-  hide all rows from everyone except Admin — useful as a deny-by-default baseline.
+- **Regular** — The filter clause is applied when the querying user matches one of the
+  subjects assigned to the filter. Use this to restrict what specific users, roles, or groups
+  can see.
+- **Base** — The filter clause is applied to **all** users _except_ those matching the assigned
+  subjects. Use this to define a default restriction that privileged subjects (e.g. the Admin
+  role subject) are exempt from. For example, a Base filter with clause `1 = 0` and the Admin
+  role subject would hide all rows from everyone except Admin - useful as a deny-by-default
+  baseline.
 
 #### Group Keys and Filter Combination
 
@@ -416,21 +494,20 @@ GET /api/v1/rowlevelsecurity/
 GET /api/v1/rowlevelsecurity/?q=(filters:!((col:tables,opr:rel_m_m,value:<dataset_id>)))
 ```
 
-**Filter RLS rules by role:**
+**Filter RLS rules by subject:**
 
 ```
-GET /api/v1/rowlevelsecurity/?q=(filters:!((col:roles,opr:rel_m_m,value:<role_id>)))
+GET /api/v1/rowlevelsecurity/?q=(filters:!((col:subjects,opr:rel_m_m,value:<subject_id>)))
 ```
 
-**View details of a specific rule** (including clause, assigned datasets, and roles):
+**View details of a specific rule** (including clause, assigned datasets, and subjects):
 
 ```
 GET /api/v1/rowlevelsecurity/<id>
 ```
 
 The response includes the filter's `name`, `filter_type` (Regular or Base), `clause`,
-`group_key`, assigned `tables` (with id, schema, and table\_name), and assigned `roles`
-(with id and name).
+`group_key`, assigned `tables` (with id, schema, and table\_name), and assigned `subjects`.
 
 :::tip Auditing RLS for virtual datasets
 To find all RLS rules that could affect a particular virtual dataset, query the list

diff --git a/docs/developer_docs/components/design-system/metadatabar.mdx b/docs/developer_docs/components/design-system/metadatabar.mdx
@@ -26,7 +26,7 @@ import { StoryWithControls } from '../../../src/components/StorybookWrapper';
 
 # MetadataBar
 
-MetadataBar displays a row of metadata items (SQL info, owners, last modified, tags, dashboards, etc.) that collapse responsively based on available width.
+MetadataBar displays a row of metadata items (SQL info, editors, last modified, tags, dashboards, etc.) that collapse responsively based on available width.
 
 ## Live Example
 
@@ -43,9 +43,9 @@ MetadataBar displays a row of metadata items (SQL info, owners, last modified, t
       title: "Click to view query"
     },
     {
-      type: "owner",
+      type: "editor",
       createdBy: "Jane Smith",
-      owners: [
+      editors: [
         "John Doe",
         "Mary Wilson"
       ],
@@ -104,9 +104,9 @@ function Demo() {
   const items = [
     { type: 'sql', title: 'Click to view query' },
     {
-      type: 'owner',
+      type: 'editor',
       createdBy: 'Jane Smith',
-      owners: ['John Doe', 'Mary Wilson'],
+      editors: ['John Doe', 'Mary Wilson'],
       createdOn: 'a week ago',
     },
     {
@@ -125,7 +125,7 @@ function Demo() {
 ```tsx live
 function MinimalMetadata() {
   const items = [
-    { type: 'owner', createdBy: 'Admin', owners: ['Admin'], createdOn: 'yesterday' },
+    { type: 'editor', createdBy: 'Admin', editors: ['Admin'], createdOn: 'yesterday' },
     { type: 'lastModified', value: '2 hours ago', modifiedBy: 'Admin' },
   ];
   return <MetadataBar items={items} />;
@@ -138,7 +138,7 @@ function MinimalMetadata() {
 function FullMetadata() {
   const items = [
     { type: 'sql', title: 'SELECT * FROM ...' },
-    { type: 'owner', createdBy: 'Jane Smith', owners: ['Jane Smith', 'John Doe', 'Bob Wilson'], createdOn: '2 weeks ago' },
+    { type: 'editor', createdBy: 'Jane Smith', editors: ['Jane Smith', 'John Doe', 'Bob Wilson'], createdOn: '2 weeks ago' },
     { type: 'lastModified', value: '3 days ago', modifiedBy: 'John Doe' },
     { type: 'tags', values: ['production', 'finance', 'quarterly'] },
     { type: 'dashboards', title: 'Used in 12 dashboards' },
@@ -158,7 +158,7 @@ function FullMetadata() {
 | `createdBy` | `string` | `"Jane Smith"` | - |
 | `modifiedBy` | `string` | `"Jane Smith"` | - |
 | `description` | `string` | `"To preview the list of dashboards go to More settings."` | - |
-| `items` | `any` | `[{"type":"sql","title":"Click to view query"},{"type":"owner","createdBy":"Jane Smith","owners":["John Doe","Mary Wilson"],"createdOn":"a week ago"},{"type":"lastModified","value":"a week ago","modifiedBy":"Jane Smith"},{"type":"tags","values":["management","research","poc"]},{"type":"dashboards","title":"Added to 3 dashboards","description":"To preview the list of dashboards go to More settings."}]` | - |
+| `items` | `any` | `[{"type":"sql","title":"Click to view query"},{"type":"editor","createdBy":"Jane Smith","editors":["John Doe","Mary Wilson"],"createdOn":"a week ago"},{"type":"lastModified","value":"a week ago","modifiedBy":"Jane Smith"},{"type":"tags","values":["management","research","poc"]},{"type":"dashboards","title":"Added to 3 dashboards","description":"To preview the list of dashboards go to More settings."}]` | Items displayed in the metadata bar. The `editor` type shows editors/creators. |
 
 ## Import