Vitor-Avila commented on code in PR #44992:
URL: https://github.com/apache/superset/pull/44992#discussion_r4195439163
##########
docs/admin_docs/configuration/alerts-reports.mdx:
##########
@@ -418,6 +418,117 @@ ALERT_REPORTS_EXECUTORS = [FixedExecutor("admin")]
Please refer to `ExecutorType` in the codebase for other executor types.
+#### Per-schedule "Run As" executor
+
+`ALERT_REPORTS_EXECUTORS` is a global, server-side setting that is invisible
to the people
+configuring alerts and reports, which makes permission problems hard to
diagnose and is
+especially painful for databases authenticated with OAuth2, where the
impersonated account
+must hold a valid token.
[SIP-209](https://github.com/apache/superset/issues/39642)
+introduces an explicit, per-schedule alternative behind the
`ALERT_REPORT_DYNAMIC_EXECUTOR`
+[feature flag](/admin-docs/configuration/configuring-superset#feature-flags):
+
+```python
+FEATURE_FLAGS = {
+ "ALERT_REPORTS": True,
+ "ALERT_REPORT_DYNAMIC_EXECUTOR": True,
+}
+```
+
+When the flag is enabled:
+
+- Every alert/report gets a **Run as** field recording which user's RBAC
permissions and
+ database credentials are used to render the content. Alerts get an additional
+ **Run alert query as** field for the alert condition SQL, so the audience of
an alert
+ does not need direct database access.
+- Admins can select **Application default** or **Specific user**:
+ * **Application default:** resolves through `ALERT_REPORTS_EXECUTORS` value.
+ * **Specific user:** User picker option.
+ Non-admins can only select themselves. They see no user search and the API
rejects
+ selecting another user. Reports scheduled from a dashboard or chart always
execute
+ as the subscribing user.
+- When a non-admin edits an alert/report that an admin configured to run as
someone else,
+ they can change its metadata (name, schedule, active state, retries) but not
its
+ content or recipients. To change those, they must first set **Run as** to
their own
+ account using **Run as me** (or ask an admin). The form explains the
restriction before
+ saving. For alerts, this action selects the current user for both content
and condition
+ execution. It takes effect on Save and requires that user to have access to
both.
+ Legacy schedules without an explicit content user also require this switch
before
+ a non-admin changes content or recipients; metadata-only edits preserve
their settings.
+- Untouched legacy schedules continue using `ALERT_REPORTS_EXECUTORS`.
**Application
+ default** preserves this behavior in the Run as selector, including when an
admin
+ clears an explicit executor. The API represents it with `run_as: null` and
+ `run_as_type: null`; omitting both fields on update preserves the stored
executor.
+ New schedules default to the creator unless an admin selects Application
default.
+ Clearing **Run alert query as** selects **Same as Run as**:
+ it follows later content-executor changes rather than copying the user at
save time.
+- A selected user that is deleted remains recorded as a **Specific user**
selection.
+ Resolving a deleted or inactive user fails rather than switching to a legacy
executor.
+ Alert SQL templates, SQL mutation hooks, authorization and database access
all use
+ the query executor's identity.
+
+`ALERT_REPORTS_EXECUTORS` is deprecated in favor of this field and will be
removed once the
+feature graduates from the flag.
+
+### Alerts & Reports configuration
+
+Admins can manage the global Alerts & Reports settings at runtime from the
**Configuration**
+button on the Alerts & Reports list page (also available through
+`GET`/`PUT /api/v1/report/configuration/`). Values are stored in the
`report_config` table;
+a setting that was never saved falls back to the corresponding
`superset_config.py` value or
+feature flag. The form saves only changed settings.
+Clearing an interval stores an explicit `null`, which means no minimum
interval; it does
+not restore the application fallback. API `null` values likewise clear
settings: attachment,
+date-format, and users-only switches become off, and domains become
unrestricted. An explicit null row
+is retained. Configuration read or decoding failures are errors, never
unrestricted defaults.
+
+| Setting | Fallback | Description |
+| --- | --- | --- |
+| Enable attachments for alerts | `ALERTS_ATTACH_REPORTS` feature flag |
Whether alerts deliver their attachment. Applies to subsequent attempts; saving
a change cancels pending attempts. |
+| Format dates in email subjects | `DATE_FORMAT_IN_EMAIL_SUBJECT` feature flag
| Render date code placeholders in alert and report email subjects using the
UTC date at delivery. |
+| Alert minimum interval | `ALERT_MINIMUM_INTERVAL` | Minimum interval between
two executions of an alert. |
+| Report minimum interval | `REPORT_MINIMUM_INTERVAL` | Minimum interval
between two executions of a report. |
+| Limit recipients to users | off | Only e-mail addresses of existing active
users are accepted as recipients. |
+| Allowed e-mail domains | any | Allow-list of e-mail domains accepted as
recipients. |
+
+Saving a stricter configuration is refused when existing alerts/reports
(including disabled schedules) would violate it
+(a recipient outside the allowed domains, an address that is not a user, or a
schedule that
+runs more often than the new minimum interval). The response lists the
impacted schedules
+in pages of ten so they can be fixed first. The recipient policy is enforced
when saving an alert/report
+and again at execution time, so a delivery to a recipient that is no longer
allowed fails
+instead of being sent. These restrictions also apply to configured recipients
of retry
+and final-failure notices. Owner/editor operational error notices are exempt;
if recipient
+validation fails during a retry notice, only eligible operational notices are
attempted.
+
+Domain matching is case-insensitive. An exact entry such as `example.com` does
not
+include subdomains. Use wildcards like `*.example.com` / `example.* `to allow
subdomains
+at any depth. Combining leading and trailing wildcards, or placing wildcards
inside a label,
Review Comment:
Clarified in a new commit.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
