rusackas commented on code in PR #43595: URL: https://github.com/apache/superset/pull/43595#discussion_r3873823930
########## docs/admin_docs/security/security.mdx: ########## @@ -243,6 +243,36 @@ Each subject in the response includes flat scalar ids (`user_id`, `role_id`, `gr than a nested object, so callers can match directly on whichever id they already have — only the id field matching the subject's `type` is populated; the others are `null`. +#### Extending Editorship with EXTRA_EDITORS_RESOLVER + +Deployments that grant edit access to a dashboard or chart through a mechanism outside +Superset's own Subject-based `editors` list — for example, a folder-permission system or an +internal directory service — can plug that logic in with `EXTRA_EDITORS_RESOLVER`: + +```python +def extra_editors_resolver(resource): + # `resource` is the Dashboard or Slice instance being checked. + # Return Subject instances, raw subject ids, or dicts with an `id` key. + return [...] + + +EXTRA_EDITORS_RESOLVER = extra_editors_resolver +``` + +The resolver's result is unioned with the resource's own `editors` for editorship checks: it +feeds `is_editor`, `raise_for_editorship`, save-as, and soft-delete restore. When +`EXTRA_EDITORS_RESOLVER` is configured, the usual lockout-prevention behavior — automatically +re-adding a non-admin who removes themselves from a resource's editors — is skipped, since the +deployment has its own way of keeping the resource editable. Review Comment: Good catch — the skip was worded as tied to the resolver being configured, but not that it applies even when the resolver returns nothing for a given resource. Clarified that in the doc. ########## docs/admin_docs/security/security.mdx: ########## @@ -243,6 +243,36 @@ Each subject in the response includes flat scalar ids (`user_id`, `role_id`, `gr than a nested object, so callers can match directly on whichever id they already have — only the id field matching the subject's `type` is populated; the others are `null`. +#### Extending Editorship with EXTRA_EDITORS_RESOLVER + +Deployments that grant edit access to a dashboard or chart through a mechanism outside +Superset's own Subject-based `editors` list — for example, a folder-permission system or an +internal directory service — can plug that logic in with `EXTRA_EDITORS_RESOLVER`: + +```python +def extra_editors_resolver(resource): + # `resource` is the Dashboard or Slice instance being checked. + # Return Subject instances, raw subject ids, or dicts with an `id` key. + return [...] + + +EXTRA_EDITORS_RESOLVER = extra_editors_resolver +``` + +The resolver's result is unioned with the resource's own `editors` for editorship checks: it +feeds `is_editor`, `raise_for_editorship`, save-as, and soft-delete restore. When +`EXTRA_EDITORS_RESOLVER` is configured, the usual lockout-prevention behavior — automatically +re-adding a non-admin who removes themselves from a resource's editors — is skipped, since the +deployment has its own way of keeping the resource editable. + +Resolved subject ids are also surfaced as `extra_editors` in the chart and dashboard `GET` +responses, so API clients can distinguish resolver-granted editorship from the resource's own +`editors` list. Review Comment: Right, it's attached post-serialization and isn't in the schema. Added a note calling that out explicitly. ########## docs/admin_docs/security/security.mdx: ########## @@ -243,6 +243,36 @@ Each subject in the response includes flat scalar ids (`user_id`, `role_id`, `gr than a nested object, so callers can match directly on whichever id they already have — only the id field matching the subject's `type` is populated; the others are `null`. +#### Extending Editorship with EXTRA_EDITORS_RESOLVER + +Deployments that grant edit access to a dashboard or chart through a mechanism outside +Superset's own Subject-based `editors` list — for example, a folder-permission system or an +internal directory service — can plug that logic in with `EXTRA_EDITORS_RESOLVER`: + +```python +def extra_editors_resolver(resource): + # `resource` is the Dashboard or Slice instance being checked. + # Return Subject instances, raw subject ids, or dicts with an `id` key. + return [...] + + +EXTRA_EDITORS_RESOLVER = extra_editors_resolver +``` + +The resolver's result is unioned with the resource's own `editors` for editorship checks: it +feeds `is_editor`, `raise_for_editorship`, save-as, and soft-delete restore. When +`EXTRA_EDITORS_RESOLVER` is configured, the usual lockout-prevention behavior — automatically +re-adding a non-admin who removes themselves from a resource's editors — is skipped, since the +deployment has its own way of keeping the resource editable. + +Resolved subject ids are also surfaced as `extra_editors` in the chart and dashboard `GET` +responses, so API clients can distinguish resolver-granted editorship from the resource's own +`editors` list. + +Because the resolver is arbitrary per-deployment Python rather than a SQL-expressible condition, +editorship it grants cannot be reflected in list-view filtering (for example, the soft-deleted +archive is scoped to editors via a SQL query) — it only takes effect on direct, per-object checks. Review Comment: Fair — the doc's 'only per-object checks' line was wrong, the resolver does run per row for list responses too. Fixed the wording. -- 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]
