Migrate current website data

[Lugrim]

No description provided.

[ShiroUsagi-san]

Is this issue still open?

[KwikKill]

I think we will not do it for now but maybe later.

[ShiroUsagi-san]

I think this is a bad idea to postpone this question, because the later we will discuss it, the harder it will be to migrate and handle conflicting data import

[Lugrim]

Maybe it's a better idea to go back from a clean database state, if we want to import previous tournaments as archives, we may bind them to a phantom user and try to bypass the model restrictions?

[Lymkwi]

I honestly think the only conflicts we will ever encounter are users, for which we can just do as follows:

• If we find a user with the same login, we can assume that it's still them and bind participation to them
• If we cannot find the same login (or similar enough), we can create a user that's deactivated and bind the participation to it

By design, users are the only conflicting data we will ever import, and it is probably not as hard as we think to handle them now or later (although, yes, as we keep waiting, we are going to add a lot of models on top of the first ones created at the moment)

[ShiroUsagi-san]

An anonymous user is kind of a pressing task, because if we want to be GDPR compliant, we will need to allow users to delete quickly their account. And this kind of user will allow to prevent tournaments to collapse to chaos

[KwikKill]

The other problem we can face is "what happened if someone create an account with the same login as a deactivated user ? Do we try to link the two, do we let the deactivated user as archive ?"
Maybe we can try migrate the data and when a new account is created, if there is a deactivated user with the same (login, email), we need to automatically replace the archive user by the new one without changing it's id.

So, we have 2 options :

• We only keep the old data as archive
• We create a migration system that handle conflicts even on account creations

[ShiroUsagi-san]

pretty neat idea, but not in our rush priority queue

[Lugrim]

The other problem we can face is "what happened if someone create an account with the same login as a deactivated user ?

It should not happen. If an user is "deactivated", it functionally means the user is deleted (GDPR is not about hiding user data, it's about actually deleting it, this includes the username)

[Lymkwi]

The other problem we can face is "what happened if someone create an account with the same login as a deactivated user ?

It should not happen. If an user is "deactivated", it functionally means the user is deleted (GDPR is not about hiding user data, it's about actually deleting it, this includes the username)

It could actually happen if we import data before someone recreates an account because they had one on the previous website and are going to participate in upcoming events (but did not recreate it before our import)