|
Taille: 2650
Commentaire: proposition : gestion des défauts
|
Taille: 3158
Commentaire: courriel en extra... victoire temporaire de Tini !
|
| Texte supprimé. | Texte ajouté. |
| Ligne 3: | Ligne 3: |
| == Table utilisateurs == | |
| 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''' --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...) |
attachment:base_utilisateurs_campus.png |
| Ligne 21: | Ligne 6: |
| == Table utilisateurs_extra == | |
| Ligne 23: | Ligne 7: |
| * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' |
les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia |
| Ligne 27: | Ligne 9: |
| == Table groupes == | |
| Ligne 29: | Ligne 10: |
| * '''id''' * '''nom''' * '''commentaires''' |
= Les utilisateurs = |
| Ligne 33: | Ligne 12: |
| == Table groupes_extra == | Table utilisateurs:: . id . login . mot_de_passe . --(courriel)-- ''passe en extra... temporairement ?'' . nom_complet . nom . prénom . genre . date_naissance . commentaires |
| Ligne 35: | Ligne 24: |
| * '''id_groupe''' * '''variable''' * '''valeur''' |
Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable . valeur |
| Ligne 39: | Ligne 29: |
| == Table abonnements == | . ''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 39: |
| * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' |
= Les groupes = |
| Ligne 47: | Ligne 41: |
| == Table organismes == | Table groupes:: . id . nom . commentaires |
| Ligne 49: | Ligne 46: |
| * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' |
Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 56: | Ligne 51: |
| == Table organismes_extra == | = Les abonnements = |
| Ligne 58: | Ligne 53: |
| * '''id_organisme''' * '''variable''' * '''valeur''' |
Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. |
| Ligne 62: | Ligne 55: |
| --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 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'' |
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 69: | Ligne 63: |
| == Table defauts_groupes_extra == * '''id_groupe''' * '''id_variable''' * '''id_defaut''' (ou : on pourrait ajouter cette colonne dans la table '''groupes_extra''') |
= Les organismes = |
| Ligne 74: | Ligne 65: |
| 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'' |
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 }}} |
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