WikiTeki /  Modifications de « Projet/GUIA/SchemaBase/HistoriquePropositionThomas »

• attachment:base_utilisateurs_campus.png

les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia

Quelques idées générales :

• les objets sont 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 ou encore /home/auf/antoine) ou de spécificités de l'utilisateur (par exemple : un attribut ou appartenance à un groupe compte_systeme lui donnerait un shell utilisable)

• un mécanisme 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 organisée de façon hiérarchique (par exemple université->faculté->département). Ainsi, si une personne est de tel département, on sait qu'elle est aussi de telle faculté et de telle université. En outre, une personne peut appartenir à plusieurs organismes ou avoir plusieurs rôles dans un même organisme via des triplets { utilisateur, organisme, fonction }.

Les utilisateurs

Table utilisateurs

• id
• login
• mot_de_passe
• courriel
• nom_complet
• nom
• prénom
• genre
• date_naissance
• commentaires

Table utilisateurs_extra

• id_utilisateur : utilisateur concerné
• variable : nom de la variable
• valeur

• Exemples de variables extra :

  • adresse (qui ne sera pas celle de l'organisme avec lequel la personne est relié, cf plus bas)
  • téléphone
  • courriel_canonique (adresse de réécriture en sortie)
  • courriel (n fois)
  • courriel_transfert (forward, quoi. à utiliser si l'adresse de contact != refer)
  • repertoire_courriels (forme serveur:/repertoire)
  • repertoire_fichiers (le HOME, par exemple sous la forme serveur:/repertoire)
  • acces_shell (0/1)

Les groupes

Table groupes

• id
• nom
• commentaires

Table groupes_extra

• id_groupe
• variable
• valeur

Les abonnements

Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps.

Table abonnements

• id_utilisateur
• id_groupe
• date_debut
• date_fin

• suspendu : mis à vrai si l'abonnement est interrompu temporairement (idée de SébastienDornano)

• commentaires

Les organismes

Ils sont hiérarchisés (arbre simple : un parent peut avoir plusieurs fils).

Table organismes

• id
• nom
• adresses
• telephones
• id_organisme_parent : pointe vers un id_organisme (0 pour la racine)
• commentaires

Table organismes_extra

• note : je ne suis pas sûr de l'utilité de ces extras

• id_organisme
• variable
• valeur

Chaque utilisateur peut être rattaché à un ou plusieurs organismes. A chaque rattachement on indique la fonction de l'utilisateur dans l'organisme, via un triplet { utilisateur, organisme, fonction }. On peut donc imaginer qu'un utilisateur puisse avoir plusieurs fonctions au sein d'un même organisme.

Table fonction

• id
• nom
• commentaires

Table fonction_extra

• note : je ne suis pas sûr de l'utilité de ces extras

• id_fonction
• variable
• valeur

Table utilisateur_organisme_fonction

• id_utilisateur
• id_organisme
• id_fonction
• date_debut (idée pompée sur la proposition de Seb)
• date_fin
• commentaires