Modifications entre les versions 2 et 35 (s'étendant sur 33 versions)
⇤ ← Version 2 à la date du 2006-10-30 10:57:17 →
Taille: 4273
Éditeur: ThomasNoël
Commentaire:
← Version 35 à la date du 2008-02-21 22:10:00 → ⇥
Taille: 4612
Éditeur: localhost
Commentaire: converted to 1.6 markup
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
Voici mes (ThomasNoël) propositions pour le système de gestion des utilisateurs.

= Idées générales =

Le système se décompose en trois parties :

 Une base de données:: elle décrit l'ensemble des utilisateurs et des abonnements associés. Elle doit avoir un schéma simple mais permettant de multiples extensions. Voir ci-dessous pour ma proposition de structure.

 Des logiciels de gestion de la base de données:: de quoi remplir et gérer la base de données, notamment :
  1. une interface Web, rapide et ergonomique
  1. une interface en ligne de commande pour permettre une gestion "système"
  1. plus tard, un application native pour Gnome ou KDE

 Des systèmes d'extraction vers le système:: tout ce qu'il faut pour extraire les données systèmes, pas exemple:
  1. les fichiers {{{/etc/passwd}}} et {{{/etc/shadow}}} pour être utilisés sur un serveur NIS
  1. les fichiers {{{/etc/aliases}}}, {{{/etc/postfix/virtual}}}, etc, pour la messagerie
  1. une base de données d'authentification MySQL
  1. une base de données MySQL pour la messagerie
  1. un arbre LDAP
  1. etc. : tout autre système actuellement utilisé pour la gestion des services utilisateurs

= Le logiciel de gestion de la base =

En utilisant un système comme Django, on simplifie la programmation. Le mode objet devrait permettre de proposer des extensisons assez facilement. En outre, l'API de gestion étant disponible en Python, on peut l'utiliser directement pour écrire les outils en ligne de commande sans ré-inventer la roue.

L'idée est donc d'avoir un système Django/Python qui proposer toute l'API de gestion : ensuite au niveau des applications on n'aura qu'à appeler l'API, sans jamais toucher directement à la base de données (pas de requête SQL directe).

= Les systèmes d'extraction =

A partir d'un système comme Django, on peut extraire les données assez facilement via des ''templates''. Pour la plupart des extractions il ne sera pas nécessaire à l'administrateur système de savoir programmer en Python.

= Schéma de la base de données =

== 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é.		 ## page was renamed from Projet/GestionDesUtilisateursDesCampus/SchemaBase/HistoriquePropositionThomas
## page was renamed from Projet/GestionDesUtilisateursDesCampus/SchemaBase
Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.
Ligne 43: Ligne 6:
== Table utilisateurs ==   {{attachment:base_utilisateurs_campus.png}}
Ligne 45: Ligne 8:
 * '''id'''
 * '''login'''
 * '''mot_de_passe'''
 * '''courriel'''
 * '''nom'''
 * '''prénom'''
 * '''genre'''
 * '''date_naissance'''
 * '''adresses'''
 * '''téléphones'''
 * '''id_organisme'''
 * '''fonction'''
 * '''commentaires'''
Ligne 59: Ligne 9:
== Table utilisateurs_extra == les sources Dia de ce schéma : [[attachment:base_utilisateurs_campus.dia]]
Ligne 61: Ligne 11:
 * '''id_utilisateur''' : utilisateur concerné
 * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'')
 * '''valeur'''
Ligne 65: Ligne 12:
== Table groupes == == Les utilisateurs ==
Ligne 67: Ligne 14:
 * '''id'''
 * '''nom'''
 * '''commentaires'''		  Table utilisateurs::
  . id
  . login
  . mot_de_passe
  . courriel
  . nom_complet
  . nom
  . prénom
  . genre
  . date_naissance
  . commentaires
Ligne 71: Ligne 26:
== Table groupes_extra ==  Table utilisateurs_extra::
  . id_utilisateur : utilisateur concerné
  . variable : nom de la variable
  . valeur
Ligne 73: Ligne 31:
 * '''id_groupe'''
 * '''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)
Ligne 77: Ligne 41:
== Table abonnements == == Les groupes ==
Ligne 79: Ligne 43:
 * '''id_utilisateur'''
 * '''id_groupe'''
 * '''date_debut'''
 * '''date_fin'''
 * '''commentaires'''		  Table groupes::
  . id
  . nom
  . commentaires
Ligne 85: Ligne 48:
== Table organismes ==  Table groupes_extra::
  . id_groupe
  . variable
  . valeur
Ligne 87: Ligne 53:
 * '''id'''
 * '''nom'''
 * '''adresses'''
 * '''telephones'''
 * '''id_parent''' : pointe vers un id_organisme (0 pour la racine)
 * '''commentaires'''		 == Les abonnements ==
Ligne 94: Ligne 55:
== Table organismes_extra == Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps.
Ligne 96: Ligne 57:
 * '''id_organisme'''
 * '''variable'''
 * '''valeur'''		  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



= Archives et idées pour le futur (à ne pas insérer dans la version 0) =

== Suivi ==

Django dispose d'un système de suivi, mais ne sera-t-il pas trop générique pour nos utilisations ? Permettra-t-il par exemple de trouver simplement le taux de réabonnement des utilisateurs ? Il faudrait peut-être travailler à une table "suivi" très générique qui disposera d'une API utilisable par tous les autres objets... Ca "surclasse" un peu Django, mais ça rendra aussi notre base de donnée utilisable par un autre système que Django, un jour...

 Table action_suivi::
  . id
  . nom (par exemple ''nouvelabonnement'', ''reabonnement'', ...)

 Table suivi::
  . type_objet
  . id_objet
  . date
  . id_action_suivi
  . donnees (permet de définir des détails sur l'action, par exemple "mensuel" pour un réabonnement)

Peut-être que quelque chose d'encore plus générique serait nécessaire ? (pas d'id_action_suivi mais juste des donnees, par exemple "reabonnement:mensuel" ou "nouvelabonnement:annuel")

 Notes::
  . l'exemple des ré-abonnements est assez mal choisi car on pourra les calculer autrement et bien plus précisément via la table ''abonnements''.
  . ... et comme je ne vois pas d'autre usage, je propose de laisser tomber ce suivi parallèle à Django ; on verra ça "plus tard" !

== UML (très basique) ==

Note à OusmaneWilane : j'ai descendu ce schéma qui n'est plus synchro avec le reste.

 . source Dia du schéma UML: [[attachment:base_utilisateurs_campus_uml.dia]]
 . SQL généré pour PostgreSQL : [[attachment:base_utilisateurs_campus.sql]]

Génération SQL avec [[http://tedia2sql.tigris.org/usingtedia2sql.html|tedia2sql]] :
{{{
   tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql
}}}

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

  • base_utilisateurs_campus.png

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

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

Archives et idées pour le futur (à ne pas insérer dans la version 0)

Suivi

Django dispose d'un système de suivi, mais ne sera-t-il pas trop générique pour nos utilisations ? Permettra-t-il par exemple de trouver simplement le taux de réabonnement des utilisateurs ? Il faudrait peut-être travailler à une table "suivi" très générique qui disposera d'une API utilisable par tous les autres objets... Ca "surclasse" un peu Django, mais ça rendra aussi notre base de donnée utilisable par un autre système que Django, un jour...

Table action_suivi
  • id

  • nom (par exemple nouvelabonnement, reabonnement, ...)

Table suivi
  • type_objet
  • id_objet
  • date
  • id_action_suivi
  • donnees (permet de définir des détails sur l'action, par exemple "mensuel" pour un réabonnement)

Peut-être que quelque chose d'encore plus générique serait nécessaire ? (pas d'id_action_suivi mais juste des donnees, par exemple "reabonnement:mensuel" ou "nouvelabonnement:annuel")

Notes

  • l'exemple des ré-abonnements est assez mal choisi car on pourra les calculer autrement et bien plus précisément via la table abonnements.

  • ... et comme je ne vois pas d'autre usage, je propose de laisser tomber ce suivi parallèle à Django ; on verra ça "plus tard" !

UML (très basique)

Note à OusmaneWilane : j'ai descendu ce schéma qui n'est plus synchro avec le reste.

Génération SQL avec tedia2sql : 

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

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