rusackas commented on code in PR #44857: URL: https://github.com/apache/superset/pull/44857#discussion_r4331105397
########## superset/migrations/versions/2026-09-30_00-00_d623a0cb6bb0_sweep_legacy_password_view_perms_from_all_roles.py: ########## @@ -0,0 +1,114 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +"""sweep legacy password-view permissions from all roles (#44626 follow-up) + +#44626 removed the legacy FAB server-rendered password reset views +(``ResetPasswordView``, ``ResetMyPasswordView``) and hid the +``UserDBModelView`` actions that redirected to them (``resetpasswords``, +``resetmypassword``). ``SupersetSecurityManager.sync_role_definitions`` was +updated to stop handing their permissions to the built-in Admin/Alpha/Gamma/ +sql_lab roles on ``superset init``, but that exclusion only applies to the +pvms list those four roles are resynced from -- it never touches a role that +already held one of these permissions before upgrading, since Superset never +re-syncs operator-defined (custom) roles. An upgraded install's custom role +that was explicitly granted self-service or admin password reset therefore +keeps the dead permission forever, contradicting UPDATING.md's "no role" +claim for that release. + +The permissions are already fully inert on every upgraded install regardless +of which role holds them: the views are never registered (so the routes +404/anything routing there raises ``BuildError``), and the ``UserDBModelView`` +actions are hidden and wired to a handler that also answers 404. This +migration is therefore pure metadata cleanup with no behavior change -- it +deletes the stale (view, permission) pairs from every role that holds them +(not just the four synced built-ins), plus the underlying ``ab_permission``/ +``ab_view_menu`` rows once orphaned. + +Revision ID: d623a0cb6bb0 +Revises: c179af013f48 +Create Date: 2026-09-30 00:00:00.000000 + +""" + +# revision identifiers, used by Alembic. +revision = "d623a0cb6bb0" +down_revision = "c179af013f48" Review Comment: Good catch @sadpandajoe, it is back on `141b8ada7731` (with the `Revises:` line to match) after rebasing onto current master, so there is a single head again. -- 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]
