|
Taille: 2257
Commentaire:
|
Taille: 4015
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| Voici ma (ThomasNoël) proposition pour la base de donnée des utilisateurs. | |
| Ligne 3: | Ligne 2: |
| = Idées générales = | attachment:base_utilisateurs_campus.png |
| Ligne 5: | Ligne 4: |
| * des utilisateurs, des groupes et des abonnements qui permettent de dire que tel utilisateur est dans tel groupe de telle à telle date | 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 |
| Ligne 7: | Ligne 9: |
| * 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é. |
* 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 12: | Ligne 14: |
| = Base = | == Les utilisateurs == |
| Ligne 14: | Ligne 16: |
| == Table utilisateurs == | Table utilisateurs:: . id . login . mot_de_passe . courriel . nom_complet . nom . prénom . genre . date_naissance . commentaires |
| Ligne 16: | Ligne 28: |
| * '''id''' * '''login''' * '''mot_de_passe''' * '''courriel''' * '''nom''' * '''prénom''' * '''genre''' * '''date_naissance''' * '''adresses''' * '''téléphones''' * '''id_organisme''' * '''fonction''' * '''commentaires''' |
Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable . valeur |
| Ligne 30: | Ligne 33: |
| == Table utilisateurs_extra == | . ''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 32: | Ligne 43: |
| * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' |
== Les groupes == |
| Ligne 36: | Ligne 45: |
| == Table groupes == | Table groupes:: . id . nom . commentaires |
| Ligne 38: | Ligne 50: |
| * '''id''' * '''nom''' * '''commentaires''' |
Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 42: | Ligne 55: |
| == Table groupes_extra == | == Les abonnements == |
| Ligne 44: | Ligne 57: |
| * '''id_groupe''' * '''variable''' * '''valeur''' |
Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. |
| Ligne 48: | Ligne 59: |
| == Table abonnements == | 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 |
| Ligne 50: | Ligne 67: |
| * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' |
== Les organismes == |
| Ligne 56: | Ligne 69: |
| == Table organismes == | Ils sont hiérarchisés (arbre simple : un parent peut avoir plusieurs fils). |
| Ligne 58: | Ligne 71: |
| * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' |
Table organismes:: . id . nom . adresses . telephones . id_organisme_parent : pointe vers un id_organisme (0 pour la racine) . commentaires |
| Ligne 65: | Ligne 79: |
| == Table organismes_extra == | Table organismes_extra:: . ''note : je ne suis pas sûr de l'utilité de ces extras'' . id_organisme . variable . valeur |
| Ligne 67: | Ligne 85: |
| * '''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