Vitor-Avila commented on code in PR #33614:
URL: https://github.com/apache/superset/pull/33614#discussion_r2113964133
##########
docs/docs/configuration/sql-templating.mdx:
##########
@@ -250,6 +250,21 @@ Will be rendered as:
SELECT * FROM users WHERE role IN ('admin', 'viewer')
```
+**Current User RLS Rules**
+
+The `{{ current_user_rls_rules() }}` macro returns an array of RLS rules
applied to the current dataset for the logged in user.
+
+If you have caching enabled in your Superset configuration, then by default
the list of RLS Rules will be used
+by Superset when calculating the cache key. A cache key is a unique identifier
that determines if there's a
+cache hit in the future and Superset can retrieve cached data.
+
+You can disable the inclusion of the roles value in the calculation of the
+cache key by adding the following parameter to your Jinja code:
+
+```python
+{{ current_user_rls_rules(add_to_cache_keys=False) }}
Review Comment:
That's a fair point. To be honest, I just copied the same content from other
macros in this doc (like `current_user_roles`) and updated them to my new macro.
I think in practice this is irrelevant, because even if you set
`add_to_cache_keys=False`, the macro returns RLS rules and cache would be
isolated by the final SQL query, so different RLS configs should not overlap.
Anyways, I'll be removing this section -- do you think I should also be
removing the parameter from the macro so it always add the result to cache keys?
--
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]
