|
Taille: 3910
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 3: | Ligne 2: |
| == Table utilisateurs == | attachment:base_utilisateurs_campus.png |
| Ligne 5: | Ligne 4: |
| * '''id''' * '''login''' * '''mot_de_passe''' * '''courriel''' * '''nom''' * '''prénom''' * '''genre''' * '''date_naissance''' * '''adresses''' * '''téléphones''' * '''id_organisme''' <!> plusieurs organismes, ça serait mieux non ? (faire une table de correspondance ''1,n'' à part) * '''fonction''' * '''commentaires''' |
les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia |
| Ligne 19: | Ligne 6: |
| . CédricProtière : oui amha pour plusieurs organismes (donc ajouter tables '''organismes''' et '''utilisateurs_organismes''') Je crois qu'il en est de même pour la fonction (on peut par exemple être enseignant chercheur et étudiant foad en même temps...) => il faut alors aussi créer les tables '''fonction''' et '''utilisateur_fonction''' . Thomas : s'il y a plusieurs organismes possible on peut effectivement imaginer une fonction pour chaque organisme. Ensuite, pour la notion d'étudiant FOAD, c'est pas pareil (ça sera vu au niveau que le gars est dans le groupe "FOAD", par exemple) . Cédric : mon exemple était mauvais. Certains utilisateurs ont plusieurs fonctions (vice-recteur de l'université, enseignant de telle faculté...) qu'il serait bon je trouve d'avoir dans nos bases, afin de profiter de cet outil pour mettre en place un annuaire informatisé des universités (quitte à ce que ça fasse doublon avec le SI de l'université : dans ce cas c'est à l'admin sys du CNF de savoir quel SI privilégier ou promouvoir...) == Table utilisateurs_extra == * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' == Table groupes == * '''id''' * '''nom''' * '''commentaires''' == Table groupes_extra == * '''id_groupe''' * '''variable''' * '''valeur''' == Table abonnements == * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' == Table organismes == * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' == Table organismes_extra == * '''id_organisme''' * '''variable''' * '''valeur''' |
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 66: | Ligne 14: |
| = La suite ne fait pas partie de la proposition de Thomas ;) = | == Les utilisateurs == |
| Ligne 68: | Ligne 16: |
| Table utilisateurs:: . id . login . mot_de_passe . courriel . nom_complet . nom . prénom . genre . date_naissance . commentaires |
|
| Ligne 69: | Ligne 28: |
| . CédricProtière : Nous pourrions créer des règles de gestion pour les défauts (par exemple : email = identifiant@pays.refer.org par défaut), ces règles pouvant être stockées dans le code ou mieux en base. D'autres défauts seraient statiques (ne dépendent pas de règles, mais du choix de la personne qui a créé un groupe) je propose de créer les tables '''defaut''' pour certaines tables ci-dessus, par exemple les tables suivantes : |
Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable . valeur |
| Ligne 73: | Ligne 33: |
| . Thomas : mon idée, c'est que les config du systèmes seront dans des fichiers de config. Je ne suis pas partisan de "tout" mettre dans la base. . Cédric : oui ! on pourrait même faire des fichiers de configuration comme dans le paquet auf-asterisk, qui prennent les dates de fin de chaque formation et qu'on met à jour à chaque dist-upgrade. OK pour les sortir de la base, donc |
. ''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 76: | Ligne 43: |
| == Table defauts_groupes == * '''id_defaut''' * '''fin_abonnement''' ''date de fin de l'abonnement prérenseignée par défaut lors de l'abonnement d'un utilisateur à ce groupe'' |
== Les groupes == |
| Ligne 80: | Ligne 45: |
| == Table defauts_groupes_extra == * '''id_groupe''' * '''id_variable''' * '''id_defaut''' (ou : on pourrait ajouter cette colonne dans la table '''groupes_extra''') |
Table groupes:: . id . nom . commentaires |
| Ligne 85: | Ligne 50: |
| Si on est forts, on peut même créer une syntaxe pour les règles (pourquoi pas type balises SPIP), qui permettraient de faire des tables du type : == Table defauts_utilisateurs == * '''id_utilisateur''' * '''regle_courriel''' ''pourrait contenir : ''#IDENTIFIANT@#PAYS.refer.org'' * '''defaut_fonction''' ''etudiant'' |
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 |
- 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