[TICKET] Custom user table

[rravelli]

Description

Passer vers une table User custom via https://code.djangoproject.com/ticket/25313#comment:24 et implémenter directement l'authentification par mail.

Definition of done

The ticket can be considered as done if all theses criteria are completed:

• [x] J'ai une table User custom
• [x] L'authentification par email n'utilise plus le EmailBackend

Technical strategy

• [x] Remplacer tout les imports de User par un get_user_table()
• [x] Créer le modèle dans l'app account
• [x] Changer AUTH_USER_MODEL à account.User dans les settings django
• [x] Modifier la migration 0001 de account et créer une migration custom comme décrit dans https://code.djangoproject.com/ticket/25313#comment:24
• [x] Changer le modèle User
  • [x] Passer le champ email en unique
  • [x] Configurer l'authentification par email : changer USERNAME_FIELD et faire un manager custom

[alexisdelage]

@rravelli Quelques remarques au sujet des user pour bien gérer les comptes temporaires, que m'avaient faites JYM à l'époque où je lui en avais parlé :

• niveau database, il faudrait définir le mail et le username en champ unique
• il faudrait aussi demander la date de naissance (cf pourquoi ci-dessous)
• pour vérifier qu'on a pas de doublon de compte, on utilise pour l'instant uniquement le mail mais ça suffit pas à cause des comptes temporaires. L'astuce serait donc de comparer le triplet (prénom, nom, date de naissance) pour vérifier que l'utilisateur n'a pas déjà créé un compte, en slugifiant prénom et nom (i.e. enlever les espaces et remplacer les é par e, etc.)
• pour le format de stockage des noms et prénoms, on les stocke actuellement en minuscules dans la DB et on les reformate à chaque fois, ce qui est assez long. Perso je serais pour stocker dans la DB les noms et prénoms déjà formatés (on les formate en TitleCase à l'inscription pour éviter les noms horribles en MAJUSCULES, et l'utilisateur peut ensuite le modifier sans reformatage de notre part si la casse est fausse (peut être le cas pour les étrangers))

Ça pourra faire un autre ticket peut-être, je le mets juste là pour pas l'oublier

[rravelli]

@rravelli Quelques remarques au sujet des user pour bien gérer les comptes temporaires, que m'avaient faites JYM à l'époque où je lui en avais parlé :

• niveau database, il faudrait définir le mail et le username en champ unique
• il faudrait aussi demander la date de naissance (cf pourquoi ci-dessous)
• pour vérifier qu'on a pas de doublon de compte, on utilise pour l'instant uniquement le mail mais ça suffit pas à cause des comptes temporaires. L'astuce serait donc de comparer le triplet (prénom, nom, date de naissance) pour vérifier que l'utilisateur n'a pas déjà créé un compte, en slugifiant prénom et nom (i.e. enlever les espaces et remplacer les é par e, etc.)
• pour le format de stockage des noms et prénoms, on les stocke actuellement en minuscules dans la DB et on les reformate à chaque fois, ce qui est assez long. Perso je serais pour stocker dans la DB les noms et prénoms déjà formatés (on les formate en TitleCase à l'inscription pour éviter les noms horribles en MAJUSCULES, et l'utilisateur peut ensuite le modifier sans reformatage de notre part si la casse est fausse (peut être le cas pour les étrangers))

Ça pourra faire un autre ticket peut-être, je le mets juste là pour pas l'oublier

Quelques remarques:

• Pour info, le username est déjà par défaut unique dans AbstractBaseUser (et donc dans le modèle actuel et le modèle custom)
• Pour la vérification, je suis pas fan de stocker les dates de naissances parce que je trouve que c'est une info assez personnelle, pas mal de personnes (dont moi) changent volontairement leur dates de naissance sur les sites. Une vérification sur la promo me parait plus simple...

[hydrielax]

Pour la vérif, 2 raisons pour utiliser les birthdate :

• c'est déjà arrivé qu'il y ait des homonymes dans la même promo (même prénom et nom) : c'est rare, mais la DSI a déjà eu le cas
• l'idée de connaître la date de naissance ensuite c'est de pouvoir proposer un module "anniversaires" pour connaître qui fête son anniv (CS le fait je crois), avec bien sûr des options de confidentialité pour masquer soit l'année, soit la date entière (et dans ce cas la personne ne figure plus dans le module d'anniversaire)