chore: deprecate rls base related filters

[villebro]

SUMMARY

This is a follow-up to the work done in #23777, more specifically this discussion: #23777 (comment)

Currently Row Level Security has a dedicated set of related base filters that makes it possible to customize the filters that are applied on the Table and Role models. These are defined on the RLS_BASE_RELATED_FIELD_FILTERS config parameter.

Having these undefined by default is counter intuitive, as it means that a user that is given RLS access will be able to see ALL datasets under the RLS table dropdown, irrespective of which tables they see under the Datasets menu. To streamline this we should just use the same base filter we use for the dataset list view (DatasourceFilter).

For roles, the PR #22526 introduced the possibility to define a base filter for Roles. To avoid having duplicated logic and to give the users a unified UX, we can reuse the Role filter that users can define via the EXTRA_RELATED_QUERY_FILTERS config flag.

SCREENSHOTS

This is the datasets view for a user that is only able to access two datasets on the instance (the Gamma user only has database access to the BurgerKing database, despite there being many other databases/datasets on the instance).

With the DASHBOARD_RBAC feature enabled and a custom Roles filter, the user was only able to see the Team-BurgerKing role:

Previously, the same user would see all tables and roles on the instance if they had RLS perms. After this change the RLS dropdowns are aligned with what's available elsewhere:

RLS tables:

RLS roles:

As a bycatch, the "Roles" title is also changed to "Excluded roles" if the filter type is set to "Base" (this is similar to how the list view):

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

[codecov]

Codecov Report

Merging #24128 (21e658e) into master (8b4222f) will not change coverage.
The diff coverage is 100.00%.

❗ Current head 21e658e differs from pull request most recent head 2f2ace3. Consider uploading reports for the commit 2f2ace3 to get more accurate results

@@           Coverage Diff           @@
##           master   #24128   +/-   ##
=======================================
  Coverage   68.25%   68.25%           
=======================================
  Files        1952     1952           
  Lines       75349    75349           
  Branches     8204     8205    +1     
=======================================
  Hits        51433    51433           
  Misses      21810    21810           
  Partials     2106     2106           

Flag	Coverage Δ
hive	53.30% <100.00%> (-0.01%)	⬇️
javascript	54.68% <100.00%> (+<0.01%)	⬆️
mysql	78.94% <100.00%> (-0.01%)	⬇️
postgres	79.02% <100.00%> (-0.01%)	⬇️
presto	53.22% <100.00%> (-0.01%)	⬇️
python	82.81% <100.00%> (-0.01%)	⬇️
sqlite	77.55% <100.00%> (-0.01%)	⬇️
unit	53.24% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
superset/config.py	91.97% <ø> (-0.05%)	⬇️
...rontend/src/features/rls/RowLevelSecurityModal.tsx	73.63% <100.00%> (+0.24%)	⬆️
superset/row_level_security/api.py	96.07% <100.00%> (+0.03%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[michael-s-molina]

Could you move this to the Breaking Changes section?

[villebro]

Oof, good catch!