fix: #33862 – Security menu missing on MySQL due to case mismatch

[caerux]

Summary

Align view permission names with their menu label so Superset creates the correct “Security” row on MySQL.

Fix

• superset/views/roles.py – class_permission_name = "Security"
• superset/views/users_list.py – class_permission_name = "Security"

Impact

Restores the Security menu on fresh MySQL installs without affecting
PostgreSQL or existing deployments.

Resolves #33862

[korbit-ai]

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

Files scanned

​

File Path	Reviewed
superset/views/roles.py	✅
superset/views/users_list.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

[github-actions]

Congrats on making your first PR and thank you for contributing to Superset! 🎉 ❤️

We hope to see you in our Slack community too! Not signed up? Use our Slack App to self-register.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.88%. Comparing base (76d897e) to head (de5fece).
Report is 2002 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #33864       +/-   ##
===========================================
+ Coverage   60.48%   72.88%   +12.39%     
===========================================
  Files        1931      559     -1372     
  Lines       76236    40402    -35834     
  Branches     8568     4245     -4323     
===========================================
- Hits        46114    29448    -16666     
+ Misses      28017     9857    -18160     
+ Partials     2105     1097     -1008     

Flag	Coverage Δ
hive	47.19% <100.00%> (-1.97%)	⬇️
javascript	?
mysql	71.87% <100.00%> (?)
postgres	71.93% <100.00%> (?)
presto	50.95% <100.00%> (-2.85%)	⬇️
python	72.85% <100.00%> (+9.34%)	⬆️
sqlite	71.44% <100.00%> (?)
unit	100.00% <ø> (+42.36%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mistercrunch]

Not sure, but I'm wondering if this can break things for people that have attached roles to it (?)

Quick grep shows more low-cap 'security':

16:52 $  git grep 'class_permission_name.*".ecurity"'
superset/views/groups.py:    class_permission_name = "security"
superset/views/logs.py:    class_permission_name = "security"
superset/views/roles.py:    class_permission_name = "security"
superset/views/users_list.py:    class_permission_name = "security"

Putting an hold! label on the PR until we can resolve this. From my understanding we'd need to align across the board and probably have a db migration script to reassign current/existing perms in the backend.

[sadpandajoe]

I think permissions are stored in a database, so if we update the name without a migration, it could break for others. I think @michael-s-molina ran into something like this but could be wrong.

[michael-s-molina]

I think permissions are stored in a database, so if we update the name without a migration, it could break for others. I think @michael-s-molina ran into something like this but could be wrong.

Yes, these types of changes without proper migrations will break existing deployments. We ran into one of these when upgrading to 4.1.

[mistercrunch]

Do we have reusable constructs / methods to easily generate permission renames as part of db migrations?