2103
Commentaire:
|
3158
courriel en extra... victoire temporaire de Tini !
|
Texte supprimé. | Texte ajouté. |
Ligne 6: | Ligne 6: |
les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia | les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia |
Ligne 14: | Ligne 16: |
. courriel | . --(courriel)-- ''passe en extra... temporairement ?'' |
Ligne 24: | Ligne 26: |
. variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'', ''adresse'', ''téléphone'') | . variable : nom de la variable |
Ligne 26: | Ligne 28: |
. ''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 41: | Ligne 53: |
Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. Un drapeau "interruption" permet de signaler si l'abonnement est momentannément interrompu (idée de SebastienDornano). | Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. |
Ligne 48: | Ligne 60: |
. interruption : mis à ''vrai'' si l'abonnement est interrompu temporairement | . suspendu : mis à ''vrai'' si l'abonnement est interrompu temporairement (idée de SébastienDornano) |
Ligne 53: | Ligne 65: |
Ils sont hiérarchisés (arbre simple : un parent peu avoir plusieurs fils). | Ils sont hiérarchisés (arbre simple : un parent peut avoir plusieurs fils). |
Ligne 63: | Ligne 75: |
Table organismes_extra (utilité à trouver):: | Table organismes_extra:: . ''note : je ne suis pas sûr de l'utilité de ces extras'' |
Ligne 68: | Ligne 81: |
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 organisme. | 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. |
Ligne 75: | Ligne 88: |
Table fonction_extra (utilité à trouver):: | Table fonction_extra:: . ''note : je ne suis pas sûr de l'utilité de ces extras'' |
Ligne 84: | Ligne 98: |
. date_debut (idée pompée sur la proposition de Seb) . date_fin |
|
Ligne 85: | Ligne 101: |
= UML (très basique) = Note à OusmaneWilane : j'ai descendu ce schéma qui n'est plus synchro avec le reste. attachment:base_utilisateurs_campus_uml.png (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.
- attachment:base_utilisateurs_campus.png
les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia
Les utilisateurs
- Table utilisateurs
- id
- login
- mot_de_passe
courriel passe en extra... temporairement ?
- 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
UML (très basique)
Note à OusmaneWilane : j'ai descendu ce schéma qui n'est plus synchro avec le reste.
- attachment:base_utilisateurs_campus_uml.png
(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