## page was renamed from Projet/GestionDesUtilisateursDesCampus/SchemaBase
  {{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 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