[TICKET] Fusionner les tables User et Student

[hydrielax]

Description

Problème : on utilise actuellement la table User par défaut de django, avec une table secondaire Student pour compléter les champs qui nous manque. Cela complique inutilement le code pour ajouter des fonctionnalités, mais pose aussi beaucoup de problèmes pour les comptes temporaires, la réinitialisation de mdp, etc...

Solution : supprimer la table User par défaut de django et créer la notre à la place, qui hérite du BaseUser de django.

Definition of Done

• J'ai une table unique User #1095
• Les informations de profils (picture, promo...) sont stockées soit dans la table User, soit dans une table Profile (mais dans tous les cas supprimer ou au moins renommer la table Student)
• Le champ email est marqué comme unique #1095
• Le champ username est marqué comme unique #1095
• Les nouveaux utilisateurs peuvent créer un username custom (idée : pouvoir taguer des gens dans le futur, sur des posts, etc...)
• Le mail peut-être modifié (pour quand on part de Centrale)
• Ajouter un rôle : Student | Permanent | External :
  • les Student ont accès à tout par défaut. On les détecte avec le mail en @(qqch.)ec-nantes.fr
  • les Permanent représentent les profs et le personnel administratif. A voir quels droits leur donner (mais certains utilisent déjà la plateforme, donc c'est mieux de les prendre en compte)
  • les Externals sont ceux qui n'ont pas de mail en ec-nantes, ie les EI0 et les Alumnis. A voir si on crée 2 rôles distincts ? Réfléchir à quels droits on veut pour quoi et dessiner le schéma de BDD correspondant

Strat technique

https://docs.djangoproject.com/en/4.2/topics/auth/customizing/#changing-to-a-custom-user-model-mid-project

[hydrielax]

@rravelli Quelques infos en plus qui pourraient t'être utiles :

• Pour exécuter une commande SQL directement sur la database, tu peux déjà tester en local en utilisant docker-compose en local (ya une page dessus dans la doc). Ensuite pour exécuter une commande SQL, il faut ouvrir un shell dans le service database (là je sais plus la commande mais ça se retrouve) et tu devrais pouvoir exécuter du SQL.
• En prod, attention : il faudra utiliser les mêmes commandes, mais en remplaçant docker compose par dcf (si tu lances une commande avec docker-compose ça va utiliser le docker compose de dev au lieu de prod et je te racontes pas les dégâts que ça peut faire...)
• Et sinon en local si tu fais tourner ta base de données postgres avec docker tu peux y accéder dans pgAdmin4