Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.
Table utilisateurs
id
login
mot_de_passe
courriel
nom
prénom
genre
date_naissance
adresses
téléphones
id_organisme
plusieurs organismes, ça serait mieux non ? (faire une table de correspondance 1,n à part) fonction
commentaires
--CédricProtière : oui amha pour plusieurs organismes (donc ajouter tables organismes et utilisateurs_organismes) Je crois qu'il en est de même pour la fonction (on peut par exemple être enseignant chercheur et étudiant foad en même temps...)
Table utilisateurs_extra
id_utilisateur : utilisateur concerné
variable : nom de la variable (par exemple : courriel_alias, homedir)
valeur
Table groupes
id
nom
commentaires
Table groupes_extra
id_groupe
variable
valeur
Table abonnements
id_utilisateur
id_groupe
date_debut
date_fin
commentaires
Table organismes
id
nom
adresses
telephones
id_parent : pointe vers un id_organisme (0 pour la racine)
commentaires
Table organismes_extra
id_organisme
variable
valeur
--CédricProtière : Nous pourrions créer des règles de gestion pour les défauts (par exemple : email = identifiant@pays.refer.org par défaut), ces règles pouvant être stockées dans le code ou mieux en base. D'autres défauts seraient statiques (ne dépendent pas de règles, mais du choix de la personne qui a créé un groupe) je propose de créer les tables defaut pour certaines tables ci-dessus, par exemple les tables suivantes :
Table defauts_groupes
id_defaut
fin_abonnement date de fin de l'abonnement prérenseignée par défaut lors de l'abonnement d'un utilisateur à ce groupe
Table defauts_groupes_extra
id_groupe
id_variable
id_defaut (ou : on pourrait ajouter cette colonne dans la table groupes_extra)
Si on est forts, on peut même créer une syntaxe pour les règles (pourquoi pas type balises SPIP), qui permettraient de faire des tables du type :
Table defauts_utilisateurs
id_utilisateur
regle_courriel pourrait contenir : #IDENTIFIANT@#PAYS.refer.org
defaut_fonction etudiant