Add confirmation step when admin removes their admin role at silo level - #3305
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
fakemonster
approved these changes
Jul 28, 2026
Contributor
Author
There's also the complicating factor that IF a user is in a group and IF that group has silo admin permissions, then the user would still have admin permissions, but it gets a bit in the weeds to get into that. On the other hand, we go with the scarier message of "This will remove your own silo access." on the "delete" flow: |
Contributor
|
i think either is basically fine, preferring your original though. It's too much to enumerate the different ways you can obtain to this permission |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When working on #3211, I noticed that a silo admin can update their own silo admin role to a role with fewer permissions (say, "viewer"), which would act as a one-way door, preventing them from un-do-ing that change. We don't want to fully prevent that from happening, but we can have a warning, just like we do for when they might delete their own role.
Keeping this outside of #3211 just because that one's long enough already, and this is mostly unrelated to that. Probably makes sense to get #3211 merged first, though.
Closes #3303