codeant-ai-for-open-source[bot] commented on code in PR #43536:
URL: https://github.com/apache/superset/pull/43536#discussion_r3867129086
##########
superset/views/user_info.py:
##########
@@ -24,11 +24,21 @@
class UserInfoView(BaseSupersetView):
+ """SPA shell for the signed-in user's own profile page.
+
+ Uses ``can_userinfo on UserInfo`` rather than ``can_read on user`` /
+ ``User``. The latter is Admin-only (``ADMIN_ONLY_VIEW_MENUS``), so
+ Alpha/Gamma were redirected to ``/superset/welcome/`` when opening
+ Settings → Info even though the menu link is shown to every
+ authenticated user. ``can_userinfo`` is already in
+ ``ACCESSIBLE_PERMS``, so stock Gamma and Alpha receive it on role sync.
+ """
+
route_base = "/"
- class_permission_name = "user"
+ class_permission_name = "UserInfo"
Review Comment:
Yes—the concern is valid. Changing `class_permission_name` changes the PVM
required by `@has_access` from the legacy target to `can_userinfo` on
`UserInfo`. Role synchronization generally adds accessible permissions but does
not migrate arbitrary custom-role grants, so custom roles holding the legacy
PVM may lose access.
The safest fix is an idempotent security-convergence migration that:
1. Detects roles containing the legacy Settings → Info PVM (for example,
`can_userinfo` on `UserDBModelView`/the deployed legacy view target).
2. Grants those roles `can_userinfo` on `UserInfo`.
3. Retains the legacy permission for compatibility; it should not grant
`can_read` on `User` or otherwise widen user management.
4. Runs during the normal role-sync/convergence path and is covered by a
regression test for a custom role.
A compatibility check in `UserInfoView` could also accept either PVM, but it
would leave the permission model ambiguous and make eventual cleanup harder.
Migrating legacy grants to the new, purpose-specific PVM preserves existing
access while keeping `User` Admin-only.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
