feat: current_user_rls_rules Jinja macro

[Vitor-Avila]

SUMMARY

This PR adds a new Jinja macro: {{ current_user_rls_rules() }}. The macro returns a list of all RLS rules applied for this user in the current dataset. It works with both embedded and non-embedded users.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Screen.Recording.2025-05-29.at.1.13.16.AM.mov

TESTING INSTRUCTIONS

Unit tests added. For manual testing:
1.. Create a virtual dataset using below SQL:

{% set rls = current_user_rls_rules() %}
select
{% if rls %}
  {% for rule in rls %}
    'RLS Clause: {{ rule|replace("'", '`')|tojson }}'
    {% if not loop.last %}
    || '</br>' ||
    {% endif %}
  {% endfor %}
{% else %}
  ''
{% endif %}
as test

2. Create an RLS mapped to this dataset and the admin role (make sure your test account is added to this role).
3. Display this dataset in a table chart.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[Vitor-Avila]

This is now cover in the previous test with parametrize

[korbit-ai]

I've completed my review and didn't find any issues.

Files scanned

​

File Path	Reviewed
superset/jinja_context.py	✅

Explore our documentation to understand the languages and file types we support and the files we ignore.

Check out our docs on how you can make Korbit work best for you and your team.

Loving Korbit!? Share us on LinkedIn Reddit and X

[betodealmeida]

Why would we want to do this? Would it allow users to see cached RLS roles that don't belong to them? — that could be a security issue.

[Vitor-Avila]

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?

[betodealmeida]

the macro returns RLS rules and cache would be isolated by the final SQL query, so different RLS configs should not overlap.

But the cache is based on the pre-rendered query, no? At least that's what I understood from @john-bodley's original PR.

[Vitor-Avila]

right, but it should still consider the RLS filters at the end, so you would only get the same query if you effectively have the same RLS config as the previous user.

Anyways, let's err on the side of cautious here, so I'll:

1. Remove this from the docs.
2. Remove support to the add_to_cache_keys param.
3. Always do self.cache_key_wrapper(json.dumps(rls_rules)) in case rls_rules has a value.

[betodealmeida]

Awesome!