Vitor-Avila commented on code in PR #44992:
URL: https://github.com/apache/superset/pull/44992#discussion_r4199928434
##########
docs/admin_docs/configuration/alerts-reports.mdx:
##########
@@ -418,6 +418,108 @@ 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 configured to run as someone else,
they can
+ change its metadata, type, and condition (database, SQL, and validator), but
not its
+ selected chart/dashboard, filters, attachment format, or recipients. To
change those,
+ they must first set **Run as** to their own account via the **Execute using
my permissions**
+ button (or ask an admin). For alerts, this action selects the current user
for both content
+ and SQL condition execution. Legacy schedules without an explicit ``run_as``
user also
+ require this switch before a non-admin changes the delivered asset or
recipients.
+- 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.
+- 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.
+
+It's possible to set a custom "Run As" tooltip value via the
`ALERT_REPORTS_RUN_AS_TOOLTIP`
+config in `superset_config.py`. This is useful if you want to provide further
context on what
+the "Application default" means. **It does not change the feature behavior**.
+`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.
+
+| Setting | Fallback | Description |
+| --- | --- | --- |
+| Enable attachments for alerts | `ALERTS_ATTACH_REPORTS` FF | Whether alerts
deliver their attachment. Applies to subsequent attempts; saving a change
cancels pending attempts. |
Review Comment:
Oh, totally. I had some logic to drop retries but ended up removing because
it would be inconsistent with other changes. Will fix this in a new commit and
resolve this one. Great catch!
--
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]
