Introduce users.is_admin column and allow admins to yank/unyank versions
#7852
Conversation
This file contains 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
Turbo87
added
C-internal 🔧
This was referenced Jan 3, 2024
LawnGnome
approved these changes
Jan 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR does multiple things, but I felt that without an actual use case for admin users their introduction wouldn't make a lot of sense...
The commit messages should explain the steps, but the short version is that this PR introduces a new
is_admincolumn on theuserstable, which default tofalse. We can manually grant this permission for the time being, and later introduce a background job that regularly syncs the data with the https://github.com/rust-lang/team/ repo.In the next step, this PR allows users with the
is_adminflag to yank/unyank crate versions that they don't own themselves. This is not granting our admins any new permissions, since such operations have previously been performed through thecrates-admin yank-versionadmin tool already, but it reduces the amount of permissions that admin users need to have. Previously they needed full permissions on Heroku to run the admin tool, and now they only need the database flag. The PR also adds explicit logging of such an admin intervention.The last part in this PR adds an
is_adminflag to the output of/api/v1/meand then uses the field to show the yank/unyank buttons on the frontend when an admin views the version list of a crate they don't own themselves.Lastly, note that this PR is implementing admin users slightly different from #6456. After thinking about the various implementation options it felt like a database flag with regular team repo sync might be easier than the environment variable approach, since a team repo sync in that case would need to be performed on server startup to work properly.