jon-coffey commented on issue #37938:
URL: https://github.com/apache/superset/issues/37938#issuecomment-3894780024

   Thank you for the clarification so far.
   
   I’d like to better understand the background of this decision. From my 
perspective, it’s still unclear:
   
   - Who made the decision to restrict viewing and managing users/roles 
exclusively to full Admins?
   - What was the original motivation for this change?
   - Was there a specific security concern or architectural reason that 
required overriding the existing granular permission model?
   
   What particularly confuses me is that the granular permissions (e.g., `list 
users`, `list roles`) still exist in the system. If these permissions are no 
longer intended to control access to the corresponding views, why are they 
still present?
   
   Additionally, I couldn’t find:
   - Any deprecation notice regarding this behavioral change  
   - Any mention in the release notes explaining that granular access control 
for user/role views was effectively replaced by an Admin-only requirement  
   
   Since this represents a significant change in access control behavior, I 
would have expected clearer communication.
   
   @EnxDev & @geido, as I understand you implemented the change—could you 
please share more context on:
   - Where the requirement originated?
   - Whether this was discussed or documented somewhere?
   - Whether the team considered maintaining permission-based access rather 
than enforcing Admin-only access?
   
   From a real-world usage perspective, there are valid scenarios (including 
ours) where trusted key users should be able to:
   - Grant permissions to other users  
   - Create new roles  
   - View users and roles  
   
   — without being granted full Admin rights.
   
   If this change was primarily security-driven, would the team be open to 
reconsidering an implementation that:
   - Restores strict permission-based access control for these views, and  
   - Keeps Admin as a superset role rather than the only allowed access path?
   
   If there is openness to adjusting this, I would be willing to contribute a 
PR. However, before investing time, I’d appreciate alignment on whether such a 
change would be considered acceptable within the project’s security model.
   
   Thank you for the clarification.


-- 
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]

Reply via email to