This repository was archived by the owner on Sep 30, 2024. It is now read-only.
rbac: oob migration fix for role assignment - #47946
Merged
Merged
Conversation
BolajiOlajide
changed the title
eseliger
approved these changes
Feb 21, 2023
| @@ -65,18 +65,29 @@ WITH user_system_role AS MATERIALIZED ( | |||
| site_admin_system_role AS MATERIALIZED ( | |||
Member
There was a problem hiding this comment.
just saw above: if this OOB doesn't do anything in the down migration, does it correctly track back to 0% progress if reverted?
Contributor
Author
There was a problem hiding this comment.
Yes. If all or some of the roles are revoked, it'll be updated.
Piszmog
approved these changes
Feb 21, 2023
coury-clark
pushed a commit
that referenced
this pull request
Feb 21, 2023
Earlier today (or some days/ months ago depending on when you're reading this), I noticed that on S2 the OOB migration for assigning roles to existing users was at 99% for quite some time. <img width="918" alt="CleanShot 2023-02-21 at 12 44 21@2x" src="https://user-images.githubusercontent.com/25608335/220336203-2fe406cb-e8bd-4c6b-9066-af14fd03d50a.png"> I did some digging to find out what happened, and I found out we had some site admins who weren't assigned the `USER` role. I confirmed they weren't newly created admins since the PR for assigning roles on creation merged pretty recently - they weren't. I suspect it's a case of the instance getting restarted when the OOB migration was in progress. The existing logic for checking users that need to be assigned roles just checked the `user_roles` table to see if you had any record; we didn't check specifically for what roles were assigned. ```sql SELECT id, site_admin FROM users u WHERE u.id NOT IN (SELECT user_id from user_roles) ``` This PR updates that query to check for the assigned roles and only sets what's needed. I also updated the test to test for this scenario. ## Test plan <!-- All pull requests REQUIRE a test plan: https://docs.sourcegraph.com/dev/background-information/testing_principles --> The test added validates that the `Up` method checks for specific role assignments on a `USER` and `SITE_ADMINISTRATOR` level.
coury-clark
added a commit
that referenced
this pull request
Feb 21, 2023
Backporting to 4.5 Original PR: Earlier today (or some days/ months ago depending on when you're reading this), I noticed that on S2 the OOB migration for assigning roles to existing users was at 99% for quite some time. <img width="918" alt="CleanShot 2023-02-21 at 12 44 21@2x" src="https://user-images.githubusercontent.com/25608335/220336203-2fe406cb-e8bd-4c6b-9066-af14fd03d50a.png"> I did some digging to find out what happened, and I found out we had some site admins who weren't assigned the `USER` role. I confirmed they weren't newly created admins since the PR for assigning roles on creation merged pretty recently - they weren't. I suspect it's a case of the instance getting restarted when the OOB migration was in progress. The existing logic for checking users that need to be assigned roles just checked the `user_roles` table to see if you had any record; we didn't check specifically for what roles were assigned. ```sql SELECT id, site_admin FROM users u WHERE u.id NOT IN (SELECT user_id from user_roles) ``` This PR updates that query to check for the assigned roles and only sets what's needed. I also updated the test to test for this scenario. ## Test plan <!-- All pull requests REQUIRE a test plan: https://docs.sourcegraph.com/dev/background-information/testing_principles --> The test added validates that the `Up` method checks for specific role assignments on a `USER` and `SITE_ADMINISTRATOR` level. ## Test plan <!-- All pull requests REQUIRE a test plan: https://docs.sourcegraph.com/dev/background-information/testing_principles --> Co-authored-by: Bolaji Olajide <25608335+BolajiOlajide@users.noreply.github.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 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.
Earlier today (or some days/ months ago depending on when you're reading this), I noticed that on S2 the OOB migration for assigning roles to existing users was at 99% for quite some time.
I did some digging to find out what happened, and I found out we had some site admins who weren't assigned the
USERrole. I confirmed they weren't newly created admins since the PR for assigning roles on creation merged pretty recently - they weren't. I suspect it's a case of the instance getting restarted when the OOB migration was in progress.The existing logic for checking users that need to be assigned roles just checked the
user_rolestable to see if you had any record; we didn't check specifically for what roles were assigned.This PR updates that query to check for the assigned roles and only sets what's needed. I also updated the test to test for this scenario.
Test plan
The test added validates that the
Upmethod checks for specific role assignments on aUSERandSITE_ADMINISTRATORlevel.