Bug: “Security” menu disappears in Superset 4 on MySQL

[caerux]

Bug description

Bug: “Security” menu disappears in Superset 4 on MySQL

	Value
Superset version	4.0.x (verified on 4.0.0 & 4.1.0-SNAPSHOT)
Metadata DB	MySQL
Regression?	Yes – Superset 3 shows the menu correctly
Impact	Admin users lose access to Security → Users / Roles / RLS / Action Log*

---

Steps to Reproduce

1. Build a local Superset 4 Docker image

2. Start a brand-new MySQL container

3. Run Superset 4 pointing at that MySQL instance

4. Log into the Superset UI as the admin user
   open the Settings navigation menu and look for the Security category.

Expected result: Security section is visible for Admin.
Actual result: Security section is missing.

(Repeat the same steps with PostgreSQL as the metadata DB and notice the menu appears, confirming the regression.)

---

Findings (database state)

Database	Entries in ab_view_menu that match %ecurity% after first init
MySQL	Only one row: "security" (all lowercase)
PostgreSQL	Two separate rows: "Security" and "security"

Screenshots/recordings

No response

Superset version

master / latest-dev

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

Hi @caerux! I'm Dosu and I’m helping the superset team.

This is a known regression in Superset 4.x when using MySQL as the metadata database. The root cause is a case sensitivity issue in the ab_view_menu table: MySQL's default collation is case-insensitive, so only one entry ('security', all lowercase) is created, while Superset expects 'Security' (capital S) for the menu to appear. This does not happen with PostgreSQL, which is case-sensitive by default.

To fix it, update the ab_view_menu table in your MySQL metadata database so that the entry is 'Security' (with a capital S). For example:

UPDATE ab_view_menu SET name='Security' WHERE name='security';

After running this, restart Superset and the Security menu should reappear for admin users. You may want to check for similar issues with other menu entries (like 'SQLLab') if you notice other missing menus. More details and confirmation of this workaround are available in this issue thread.

If you are running Superset in Docker, make sure the mysqlclient driver is installed in your image, as missing drivers can cause incomplete migrations and related permission issues. If the problem persists, check your Superset logs for any errors related to permissions or menu rendering.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[caerux]

Hi @dosu — thanks for jumping in and pointing out the quick SQL tweak. I'm aiming for a solution that works on a clean install so no manual database manipulation is needed.

During testing I found that changing the two view classes…

superset/views/roles.py and superset/views/users_list.py

class_permission_name = "Security"

…lets superset init populate MySQL with the proper "Security" row right away, so the menu shows up automatically. The same build still works fine on PostgreSQL.

Would it be possible to get that (or an equivalent) change merged so new MySQL deployments are trouble-free out of the box?

[dosubot]

Your proposed change—setting class_permission_name = "Security" in both superset/views/roles.py and superset/views/users_list.py—is a safe and effective fix for the MySQL case-sensitivity issue. This approach aligns with how other menus (like SQLLab) are handled and ensures consistent behavior across all supported databases. There are no internal references to the lowercase "security" string, so this change won’t break existing code or configs, and it works fine on PostgreSQL as well. The only minor side effect is that old installs may have orphaned lowercase permissions, which are harmless.

There are no existing pull requests for this fix, but similar issues have been discussed for other menus (like SQLLab), and the consensus is that aligning permission names with the menu label is the right approach for cross-database compatibility (example). If you submit a PR with this change, it should be straightforward to review and merge, as it improves out-of-the-box experience for MySQL and avoids manual DB tweaks. You might want to mention in the PR description that this resolves the regression described in this thread and cite the SQLLab precedent.

Let me know if you want any help drafting the PR description or with anything else!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}