Idea #12702
closed
Migrate user accounts
Description
New API end point to migrate user accounts, admin only, "old" UUID is existing user, "new" UUID is one that doesn't exist yet.
If the target exists, it is an error.
All records (links, collections, projects, jobs, pipelines, etc) owned by old user are reassigned to new user.
All head/tail_uuid of the old user are changed to the new user.
API tokens associated with old user are migrated.
SSH keys associated with the old user are migrated.
User keeps old username
Old user should be completely removed from system after migration.
The migration should be done in a transaction so that a server crash will not result in a half-migrated state.
Related issues
Updated by Peter Amstutz almost 7 years ago
- Related to Feature #12626: [API] Merge user accounts (redirect=true case) added
Updated by Tom Morris almost 7 years ago
- Target version changed from To Be Groomed to 2017-12-20 Sprint
Updated by Peter Amstutz almost 7 years ago
- Target version changed from 2017-12-20 Sprint to 2018-01-17 Sprint
Updated by Peter Amstutz almost 7 years ago
- Assigned To deleted (
Peter Amstutz)
Updated by Tom Clegg almost 7 years ago
- Related to Idea #12705: Documentation/helper scripts for migrating users to federated identity added
Updated by Tom Clegg almost 7 years ago
12702-migrate-user @ 87647b5d3d72ae0c291fcdf1ee3b4a46b3af91c0
Updated by Tom Clegg almost 7 years ago
- Category set to API
- Status changed from New to In Progress
Updated by Tom Clegg almost 7 years ago
12702-migrate-user @ 086b27a27c844178ee52a9c4186d970689147628
Updated by Lucas Di Pentima almost 7 years ago
- File
services/api/test/functional/arvados/v1/users_controller_test.rb- Both tests seem to be almost identical, maybe it would be convenient to reduce them to a list iteration of
[user, expected]values?
- Both tests seem to be almost identical, maybe it would be convenient to reduce them to a list iteration of
- Is the system user being avoided on this operation? If not, should it be?
- Would it be convenient to avoid migrating the current admin user that’s requesting the operation?
- A couple tests failed on my local
service/apirun, they don’t seem to be related but just in case:services/api/test/functional/arvados/v1/filters_test.rb:183
Updated by Tom Clegg almost 7 years ago
Lucas Di Pentima wrote:
- File
services/api/test/functional/arvados/v1/users_controller_test.rb
- Both tests seem to be almost identical, maybe it would be convenient to reduce them to a list iteration of
[user, expected]values?
Indeed. Combined into one parameterized test.
- Is the system user being avoided on this operation? If not, should it be?
Good idea. Added checks + tests for system_user and anonymous_user.
- Would it be convenient to avoid migrating the current admin user that’s requesting the operation?
AFAICS updating the current user should work the same as any other. Added a test case.
- A couple tests failed on my local
service/apirun, they don’t seem to be related but just in case:
services/api/test/functional/arvados/v1/filters_test.rb:183
.*Filter.* passing for me. We'll see how this goes: https://ci.curoverse.com/job/developer-run-tests/546/
12702-migrate-user @ 680ffd64dac92aec8ad94454334db9ae69b95b56
Updated by Lucas Di Pentima almost 7 years ago
This LGTM. Test run failed due to a misconfigured Jenkins, as Fernando mentioned.
Updated by Anonymous almost 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|b5a8d7052ff461073496627aef8e2e0c29901a19.