Idea #12702: Migrate user accounts - Arvados

Custom queries

All assigned issues
All issues assigned for grooming
My issues for grooming
My issues for grooming (no story pts)
Prioritized open issues

Actions

Copy link

Idea #12702

closed

Migrate user accounts

Added by Peter Amstutz about 7 years ago. Updated almost 7 years ago.

Status:

Resolved

Priority:

Normal

Assigned To:

Tom Clegg

Category:

API

Target version:

2018-01-17 Sprint

Start date:

01/05/2018

Due date:

Story points:

2.0

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.

Subtasks 1 (0 open — 1 closed)

Task #12775: Review 12702-migrate-user

Resolved

Tom Clegg

01/05/2018

Actions

Related issues 2 (0 open — 2 closed)

	Related to Arvados - Feature #12626: [API] Merge user accounts (redirect=true case)	Resolved	Tom Clegg	05/03/2018			Actions
	Related to Arvados - Idea #12705: Documentation/helper scripts for migrating users to federated identity	Resolved	Tom Clegg	01/11/2018			Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Peter Amstutz about 7 years ago

Description updated (diff)

Actions

Copy link

Updated by Peter Amstutz about 7 years ago

Related to Feature #12626: [API] Merge user accounts (redirect=true case) added

Actions

Copy link

Updated by Peter Amstutz about 7 years ago

Description updated (diff)

Actions

Copy link

Updated by Peter Amstutz about 7 years ago

Description updated (diff)

Actions

Copy link

Updated by Peter Amstutz about 7 years ago

Story points set to 2.0

Actions

Copy link

Updated by Tom Morris about 7 years ago

Target version changed from To Be Groomed to 2017-12-20 Sprint

Actions

Copy link

Updated by Peter Amstutz about 7 years ago

Assigned To set to Peter Amstutz

Actions

Copy link

Updated by Peter Amstutz almost 7 years ago

Target version changed from 2017-12-20 Sprint to 2018-01-17 Sprint

Actions

Copy link

#10

Updated by Peter Amstutz almost 7 years ago

Assigned To deleted (~~Peter Amstutz~~)

Actions

Copy link

#11

Updated by Tom Clegg almost 7 years ago

Assigned To set to Tom Clegg

Actions

Copy link

#12

Updated by Tom Clegg almost 7 years ago

Related to Idea #12705: Documentation/helper scripts for migrating users to federated identity added

Actions

Copy link

#13

Updated by Tom Clegg almost 7 years ago

12702-migrate-user @ 87647b5d3d72ae0c291fcdf1ee3b4a46b3af91c0

Actions

Copy link

#14

Updated by Tom Clegg almost 7 years ago

Category set to API
Status changed from New to In Progress

Actions

Copy link

#15

Updated by Tom Clegg almost 7 years ago

12702-migrate-user @ 086b27a27c844178ee52a9c4186d970689147628

Actions

Copy link

#16

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?
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/api run, they don’t seem to be related but just in case:
- services/api/test/functional/arvados/v1/filters_test.rb:183

Actions

Copy link

#17

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/api run, 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

Actions

Copy link

#18