les sources Dia de ce schéma : 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 extensions, éventuellement en fonction de conditions locales (exemple: homedir du type /home/a/n/antoine ou /home/auf/frederic) ou de spécificités de l'utilisateur (par exemple l'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 ou un groupe. Ces champs extra sont principalement utilisé par les extensions. On peut imaginer que la présence d'un champ extra { variable = shell, valeur = /bin/csh } donnera un c-shell à un utilisateur.

• 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)
• D'une façon générale, chaque extension au système proposera des champs extra à renseigner

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

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 utilisateur_organisme_fonction

• id_utilisateur
• id_organisme
• id_fonction
• date_debut
• date_fin
• commentaires

Annexes

Historique des propositions, dans lesquelles il reste des idées !

• /HistoriquePropositionBase

• /HistoriquePropositionJC

• /HistoriquePropositionSebastien

• /HistoriquePropositionThomas

• /HistoriquePropositionTini