|
Taille: 3731
Commentaire:
|
Taille: 4015
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs. |
|
| Ligne 6: | Ligne 4: |
| 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 |
|
| Ligne 17: | Ligne 6: |
| les sources Dia du schéma UML : attachment:base_utilisateurs_campus_uml.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 }. |
| Ligne 19: | Ligne 13: |
| SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql | |
| Ligne 21: | Ligne 14: |
| = Les utilisateurs = | == Les utilisateurs == |
| Ligne 37: | Ligne 30: |
| . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'', ''adresse'', ''téléphone'') | . variable : nom de la variable |
| Ligne 40: | Ligne 33: |
| Tini voudrait tout passer en champ extra ../PropositionTini ... mais... je sais pas, qu'en pensez-vous ? . 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 ;) |
. ''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 44: | Ligne 43: |
| = Les groupes = | == Les groupes == |
| Ligne 56: | Ligne 55: |
| = Les abonnements = | == Les abonnements == |
| Ligne 68: | Ligne 67: |
| = Les organismes = | == Les organismes == |
| Ligne 106: | Ligne 105: |
- 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