rusackas commented on code in PR #43591: URL: https://github.com/apache/superset/pull/43591#discussion_r3873831328
########## docs/admin_docs/security/security.mdx: ########## @@ -583,6 +583,24 @@ SELECT * FROM ( queries run against tables that have associated datasets with RLS filters will then have the appropriate predicates injected automatically. +#### RLS Indicator in the Dataset List and Explore + +When a dataset has one or more RLS filters that apply to it, Superset shows a lock +icon badge next to the dataset name in the **Datasets** list and next to the dataset +selector in **Explore**. Hovering over the badge shows a tooltip listing each +applicable filter's name, filter type (Regular or Base), group key (if any), assigned +roles, and clause. Review Comment: Fair point — the tooltip data actually comes from the filter's `subjects`, which can be users or groups, not just roles. Clarified the wording. ########## docs/admin_docs/security/security.mdx: ########## @@ -583,6 +583,24 @@ SELECT * FROM ( queries run against tables that have associated datasets with RLS filters will then have the appropriate predicates injected automatically. +#### RLS Indicator in the Dataset List and Explore + +When a dataset has one or more RLS filters that apply to it, Superset shows a lock +icon badge next to the dataset name in the **Datasets** list and next to the dataset +selector in **Explore**. Hovering over the badge shows a tooltip listing each +applicable filter's name, filter type (Regular or Base), group key (if any), assigned +roles, and clause. + +This badge also surfaces filters that are inherited from the physical tables +referenced by a virtual (SQL-based) dataset, as described above. Inherited filters +are marked "from underlying table" in the tooltip, and a summary note is shown +whenever any of the listed filters are inherited rather than assigned directly to +the dataset. Review Comment: Right, inherited-filter detection depends on the SQL parser matching table/schema/database — added a note that it's best-effort and can silently miss unparseable or unmatched references. ########## docs/admin_docs/security/security.mdx: ########## @@ -583,6 +583,24 @@ SELECT * FROM ( queries run against tables that have associated datasets with RLS filters will then have the appropriate predicates injected automatically. +#### RLS Indicator in the Dataset List and Explore + +When a dataset has one or more RLS filters that apply to it, Superset shows a lock +icon badge next to the dataset name in the **Datasets** list and next to the dataset +selector in **Explore**. Hovering over the badge shows a tooltip listing each +applicable filter's name, filter type (Regular or Base), group key (if any), assigned +roles, and clause. + +This badge also surfaces filters that are inherited from the physical tables +referenced by a virtual (SQL-based) dataset, as described above. Inherited filters +are marked "from underlying table" in the tooltip, and a summary note is shown +whenever any of the listed filters are inherited rather than assigned directly to +the dataset. + +The badge is a visibility aid only — it does not change which filters are applied to +a query. Use the RLS REST API described below if you need to confirm exactly which +filters affect a dataset. Review Comment: The Auditing RLS for virtual datasets tip right below this already covers that gap — it says to also check the physical datasets' filters since the list endpoint only returns direct associations. Leaving as-is. -- 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]
