Superset 6.1. Log in to Superset using the admin role. In the settings, there are no security-related tags, and in the user section, there are no profile modifications. How should this be handled?

[dragon-feng]

Superset 6.1. Log in to Superset using the admin role. In the settings, there are no security-related tags, and in the user section, there are no profile modifications. How should this be handled?

[gitsult4n]

No feature flag hides the Security menu in 6.x. The defaults are all permissive at tag 6.1.0: SUPERSET_SECURITY_VIEW_MENU = True (superset/config.py:93), FAB_ADD_SECURITY_VIEWS = True and FAB_ADD_SECURITY_API = True (config.py:1630-1631). The three FAB_ADD_SECURITY_PERMISSION* flags are False, but they have been since 0.36 and only hide Base Permissions and Views/Menus, not List Users or List Roles.

The menu is missing because of permission rows, and there are two ways to get there.

First, superset init was never run after the upgrade. The web process builds AppBuilder with appbuilder = AppBuilder(update_perms=False) (superset/extensions/__init__.py:130), so it never creates permissions. Only the CLI does:

# superset/cli/main.py:84
appbuilder.add_permissions(update_perms=True)
security_manager.sync_role_definitions()

UPDATING.md for 6.0.0 says this outright for the migrated Roles view, since Users, Roles and Groups became React pages in 6.0.0. Fix:

superset db upgrade
superset init     # webserver stopped

Second, and this one survives a correct superset init: if your metadata database is MySQL or MariaDB, you are hitting a real 6.1.0 bug. The five new views declare class_permission_name = "security" in lowercase (superset/views/roles.py:28, same in users_list.py, groups.py, user_registrations.py), while the menu category is "Security". ab_view_menu.name is unique and MySQL's default collation is case insensitive, so only the lowercase row gets created. Flask-AppBuilder then compares case sensitively, menu.py:79:

elif item.name not in allowed_menus:
    continue

and allowed_menus is filled from the database spelling, pvm.view_menu.name (security/manager.py:1578). 'Security' in {'security'} is False, so the whole category drops out, and with it the Settings section.

Check which one you have:

SELECT vm.name, p.name, r.name
FROM ab_permission_view_role pvr
JOIN ab_permission_view pv ON pv.id = pvr.permission_view_id
JOIN ab_view_menu vm ON vm.id = pv.view_menu_id
JOIN ab_permission p ON p.id = pv.permission_id
JOIN ab_role r ON r.id = pvr.role_id
WHERE p.name = 'menu_access'
  AND LOWER(vm.name) IN ('security','list users','list roles','list groups');

No rows for Admin means case one. Rows with a lowercase security means case two, and the fix until you can upgrade is:

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

then superset init and restart. Upstream this is PR #40527, "fix: correct Security menu case for MySQL deployments", merged 2026-07-03 with migration b4a3f2e1d0c9. I checked today: it is on master only, the 6.1 and 6.2 branches still carry the lowercase string, so 6.1.0 has no released fix.

On the profile: Settings, User, Info is rendered for every logged-in user, but /user_info/ requires read on the Admin-only user view menu, so anyone who is not effectively Admin gets bounced to /superset/welcome/. That is open issue #43089. A real Admin with synced permissions does get Reset my password and Edit user there, so if you do not, the account is not resolving as Admin. Worth confirming with superset fab list-users.

Everything above was read at tag 6.1.0 with Flask-AppBuilder 5.0.2, the version it pins. I did not stand up a 6.1 instance, so the SQL is a diagnosis to run, not a reproduction.

[dragon-feng]

The issue has been resolved, thank you!