-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AC-2538] Member modal - limit admin access - fix ManageUsers custom permission #4032
[AC-2538] Member modal - limit admin access - fix ManageUsers custom permission #4032
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4032 +/- ##
==========================================
- Coverage 38.30% 38.30% -0.01%
==========================================
Files 1195 1195
Lines 58232 58223 -9
Branches 5584 5583 -1
==========================================
- Hits 22307 22302 -5
+ Misses 34873 34871 -2
+ Partials 1052 1050 -2 ☔ View full report in Codecov by Sentry. |
New Issues
Fixed Issues
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like centralizing the authorized boolean as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! I really like that we can simply return a boolean for the helpers and don't need to pass in the requirement everywhere!
Type of change
Objective
Fix bug for Flexible Collections v1: the
BulkCollectionAuthorizationHandler
did not authorize the "Manage Users" or "Manage Groups" custom permissions, which broke the flow for #3934 (and would've for #3998).This requires that we split the
ModifyAccess
operation intoModifyUserAccess
andModifyGroupAccess
, to match the granularity of the custom permissions, and use these new operations where required.Code changes
ModifyAccess
and replace it withModifyUserAccess
andModifyGroupAccess
ModifyUserAccess
, which is always what you're doing via theOrganizationUsersController
context.Succeed
from the top-level method only. I really like how this simplified the handlerUpdate
operation, e.g. if you canUpdate
then you canModifyUserAccess
. There's an argument for splitting these out completely (so thatUpdate
only refers to the collection and not its access) but I decided to pull up for now.Before you submit
dotnet format --verify-no-changes
) (required)