|
Taille: 2650
Commentaire: proposition : gestion des défauts
|
Taille: 2190
Commentaire: idées de Sébastien Dornano (merci !)
|
| 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 == | les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia |
| Ligne 23: | Ligne 8: |
| * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' |
= Les utilisateurs = |
| Ligne 27: | Ligne 10: |
| == Table groupes == | Table utilisateurs:: . id . login . mot_de_passe . courriel . nom . nom_2 : notamment pour les femmes mariées et les changements de nom (idée de SebastienDornano) . prénom . genre . date_naissance . adresses . téléphones . commentaires |
| Ligne 29: | Ligne 24: |
| * '''id''' * '''nom''' * '''commentaires''' |
Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') . valeur |
| Ligne 33: | Ligne 29: |
| == Table groupes_extra == | = Les groupes = |
| Ligne 35: | Ligne 31: |
| * '''id_groupe''' * '''variable''' * '''valeur''' |
Table groupes:: . id . nom . commentaires |
| Ligne 39: | Ligne 36: |
| == Table abonnements == | Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 41: | Ligne 41: |
| * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' |
= Les abonnements = |
| Ligne 47: | Ligne 43: |
| == Table organismes == | 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). |
| Ligne 49: | Ligne 45: |
| * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' |
Table abonnements:: . id_utilisateur . id_groupe . date_debut . date_fin . interruption : mis à ''vrai'' si l'abonnement est interrompu temporairement . commentaires |
| Ligne 56: | Ligne 53: |
| == Table organismes_extra == | = Les organismes = |
| Ligne 58: | Ligne 55: |
| * '''id_organisme''' * '''variable''' * '''valeur''' |
Ils sont hiérarchisés (arbre simple : un parent peu avoir plusieurs fils). |
| Ligne 62: | Ligne 57: |
| --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 organismes:: . id . nom . adresses . telephones . id_organisme_parent : pointe vers un id_organisme (0 pour la racine) . commentaires |
| Ligne 69: | Ligne 65: |
| == Table defauts_groupes_extra == * '''id_groupe''' * '''id_variable''' * '''id_defaut''' (ou : on pourrait ajouter cette colonne dans la table '''groupes_extra''') |
Table organismes_extra (utilité à trouver):: . id_organisme . variable . valeur |
| Ligne 74: | Ligne 70: |
| 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'' |
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. Table fonction:: . id . nom . commentaires Table fonction_extra (utilité à trouver):: . id_fonction . variable . valeur Table utilisateur_organisme_fonction:: . id_utilisateur . id_organisme . id_fonction . commentaires |
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
- nom
nom_2 : notamment pour les femmes mariées et les changements de nom (idée de SebastienDornano)
- prénom
- genre
- date_naissance
- adresses
- téléphones
- commentaires
- Table utilisateurs_extra
- id_utilisateur : utilisateur concerné
variable : nom de la variable (par exemple : courriel_alias, homedir)
- valeur
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. Un drapeau "interruption" permet de signaler si l'abonnement est momentannément interrompu (idée de SebastienDornano).
- Table abonnements
- id_utilisateur
- id_groupe
- date_debut
- date_fin
interruption : mis à vrai si l'abonnement est interrompu temporairement
- commentaires
Les organismes
Ils sont hiérarchisés (arbre simple : un parent peu 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 (utilité à trouver)
- 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 organisme.
- Table fonction
- id
- nom
- commentaires
- Table fonction_extra (utilité à trouver)
- id_fonction
- variable
- valeur
- Table utilisateur_organisme_fonction
- id_utilisateur
- id_organisme
- id_fonction
- commentaires