Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.

• attachment:base_utilisateurs_campus.png

Version UML (Très Basique) [http://tedia2sql.tigris.org/usingtedia2sql.html http://tedia2sql.tigris.org/usingtedia2sql.html]

Exemple génération SQL:

   tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql

• attachment:base_utilisateurs_campus_uml.png

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

les sources Dia du schéma UML : attachment:base_utilisateurs_campus_uml.dia

SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql

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 (par exemple : courriel_alias, homedir, adresse, téléphone)

• valeur

Tini voudrait tout passer en champ extra ../PropositionTini ... mais... je sais pas, qu'en pensez-vous ? (et finalement, à Niamey, comme tout le monde était gentil, il a renoncé)

• MS: Pourquoi? Pourquoi tu préfères avoir beaucoup de renseignements dans la table principale et Tini moins? Zavez p'tet des arguments qui sautent pas aux yeux. Sur le principe, ok, pour abonner un utilisateur, on a pas besoin de grand chose, id, nom/prénom, login. Mais à l'usage, on ne prendra jamais le temps de remplir les extras si on ne le fait pas dès le début.(J'imagine que la table principale, tous les champs sont à renseigner, alors qu'en extra non.)

• TN : tu as vu juste et je suis d'accord avec ton raisonnement. Moi je préfère que la table de base contienne quand même quelques infos "obligatoires". Par ailleurs pour l'API ça pourrait quand même être plus simple à gérer. En fait, Jérôme avait surtout un soucis avec la prédominance du champ "courriel" sur les possibles champs extra "courriel_forward" et "courriel_alias". Je ne sais pas s'il a avancé dans ses reflexions pendant qu'il dé-spaghettisait le firewall de Niamey

• MS : Pourquoi "courriel_forward" et "courriel_alias"? On a besoin d'enregistrer tant d'info sur nos utilisateurs? Un seul mail, celui fournit par le CNF, les utilisations de yahoo/hotmail n'étant pas recommandé.
• TN : parce que ça serait bien dommage de s'en priver, et que y'a toujours des cas particuliers à gérer... Ne serait-ce que pour les mails @auf.org (on a tous deux adresses : @XX.auf.org et @auf.org)

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