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...) => il faut alors aussi créer les tables fonction et utilisateur_fonction

• Thomas : s'il y a plusieurs organismes possible on peut effectivement imaginer une fonction pour chaque organisme. Ensuite, pour la notion d'étudiant FOAD, c'est pas pareil (ça sera vu au niveau que le gars est dans le groupe "FOAD", par exemple)
  • Cédric : mon exemple était mauvais. Certains utilisateurs ont plusieurs fonctions (vice-recteur de l'université, enseignant de telle faculté...) qu'il serait bon je trouve d'avoir dans nos bases, afin de profiter de cet outil pour mettre en place un annuaire informatisé des universités (quitte à ce que ça fasse doublon avec le SI de l'université : dans ce cas c'est à l'admin sys du CNF de savoir quel SI privilégier ou promouvoir...)

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

La suite ne fait pas partie de la proposition de Thomas ;)

• 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 :

• Thomas : mon idée, c'est que les config du systèmes seront dans des fichiers de config. Je ne suis pas partisan de "tout" mettre dans la base.
  • Cédric : oui ! on pourrait même faire des fichiers de configuration comme dans le paquet auf-asterisk, qui prennent les dates de fin de chaque formation et qu'on met à jour à chaque dist-upgrade. OK pour les sortir de la base, donc

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