Modifications entre les versions 1 et 6 (s'étendant sur 5 versions)
⇤ ← Version 1 à la date du 2006-10-19 09:33:00 →
Taille: 2257
Éditeur: ThomasNoël
Commentaire:
← Version 6 à la date du 2006-11-02 12:03:32 → ⇥
Taille: 2736
Éditeur: CédricProtière
Commentaire:
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
Voici ma (ThomasNoël) proposition pour la base de donnée des utilisateurs.

= Idées générales =

 * des utilisateurs, des groupes et des abonnements qui permettent de dire que tel utilisateur est dans tel groupe de telle à telle date
 * la base n'est pas destinée à être utilisée telle quelle pour l'authentification ou la gestion système : des ''backends'' sont disponibles pour créer, à partir de cette base, les données système nécessaires (fichiers ''passwd+shadow'', base MySQL-auth, arbre LDAP, htpasswd, etc).
 * par défaut la base ne contient pas de données purement "système" : ces données (comme le shell, la homedir, etc) sont calculées par les backend, éventuellement en fonction de conditions locales (exemple: homedir du type /home/a/n/antoine).
 * un mecanisme de champ "extra" permet d'étendre les tables en associant des variables à un utilisateur, un groupe ou autre (merci JérômeSantini pour cette chouette idée)
 * la gestion des organismes d'appartenance est hierarchisée (par exemple université->faculté->département). Ainsi, si une personne est de tel département, on sait qu'elle est aussi de telle fac et de telle université.


= Base =		 Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.
Ligne 26: Ligne 15:
 * '''id_organisme'''  * '''id_organisme''' <!> plusieurs organismes, ça serait mieux non ? (faire une table de correspondance ''1,n'' à part)
Ligne 29: Ligne 18:
--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'''
Ligne 70: Ligne 61:

--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''

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

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

Projet/GUIA/SchemaBase/HistoriquePropositionThomas (dernière édition le 2008-02-21 22:10:00 par localhost)