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 4299 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?

[rusackas]

Hi @caerux 👋

This PR has been on hold for about 6 months. Per the discussion, this change needs a DB migration to avoid breaking existing deployments that have roles attached to the current permission names.

@mistercrunch asked if there are reusable constructs/methods to easily generate permission renames as part of DB migrations - that might be a good starting point.

Are you still interested in working on this? If so, adding a migration would unblock the PR. If you need help or guidance on the migration approach, feel free to ask!

Thanks for your contribution!

[rusackas]

I accidentally picked up the same piece of work over on #40527

Happy to close this in favor of that, or vice versa. Review(s) appreciated if you want to help merge the new one.

[rusackas]

Thanks for digging into this @caerux, the diagnosis is right. As I mentioned I picked up the work over in #40527 (still open), so I'll close this in favor of that one, but ping me if you think there's value here I'm missing and we'll reopen this. Reviews on #40527 very welcome if you'd like to help land it. Thank you once again!