Open rdgoite opened 4 years ago
For the first bullet point, we can implement the migration in some sort of just-in-time basis where the process runs the next time the newly signed up User requests for all their Projects. The Accounts need to be flagged to ensure that this runs only once for each User.
I believe we can use the migrations solution in core for the one-time migrations.
For projects that have no identifiable owner or one in Fusillade, can we treat them as a special case, such that they can only be changed by wranglers? I feel this would be fine for legacy projects though @clairerye would need to approve this.
I had a quick conversation about this with @clairerye and I think we've agreed that in the short term, the preferred approach here is to ask the Wranglers for a list of Projects that they want to be under their Accounts.
Check the spreadsheet with Projects and their ownership.
I would like to assess the impact of rolling out the new account system and whether it presents a broader problem, but it’s really hard for me to understand the scope of the issue here. How many projects/people does this apply to?
The linked spreadsheet is just blank: should this contain a list of projects? The minimum information I need is to know how many “unowned” projects the migration is going to create.
Moving this to Product Backlog for prioritization.
ad-hoc migration has no negative consequences on the data itself, just visualisation issues, which we can fix as we go
Slack discussion: https://embl-ebi-ait.slack.com/archives/C0103DEJ82C/p1590059839130400
Rolling out the new Account system that enables us to discern between User roles has left previously created Projects with invalid owner references. This means Users who have previously created Projects through our system are not able to view those Projects as theirs. In addition, some legacy Projects that were created while we still were using identity mechanisms other than Elixir AAI do not contain enough information for us to determine their owners in our new system.