|
Taille: 3216
Commentaire:
|
Taille: 1719
Commentaire: chaque utilisateur peut être dans pls organismes, avec plusieurs fonctions éventuellement
|
| Texte supprimé. | Texte ajouté. |
| Ligne 3: | Ligne 3: |
| == Table utilisateurs == | = Les utilisateurs = |
| Ligne 5: | Ligne 5: |
| * '''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''' |
Table utilisateurs:: . id . login . mot_de_passe . courriel . nom . prénom . genre . date_naissance . adresses . téléphones . commentaires |
| Ligne 19: | Ligne 18: |
| . 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) |
Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') . valeur |
| Ligne 23: | Ligne 23: |
| == Table utilisateurs_extra == | = Les groupes = |
| Ligne 25: | Ligne 25: |
| * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' |
Table groupes:: . id . nom . commentaires |
| Ligne 29: | Ligne 30: |
| == Table groupes == | Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 31: | Ligne 35: |
| * '''id''' * '''nom''' * '''commentaires''' |
= Les abonnements = |
| Ligne 35: | Ligne 37: |
| == Table groupes_extra == | Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. |
| Ligne 37: | Ligne 39: |
| * '''id_groupe''' * '''variable''' * '''valeur''' |
Table abonnements:: . id_utilisateur . id_groupe . date_debut . date_fin . commentaires |
| Ligne 41: | Ligne 46: |
| == Table abonnements == | = Les organismes = |
| Ligne 43: | Ligne 48: |
| * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' |
Ils sont hiérarchisés (arbre simple : un parent peu avoir plusieurs fils). |
| Ligne 49: | Ligne 50: |
| == Table organismes == | Table organismes:: . id . nom . adresses . telephones . id_organisme_parent : pointe vers un id_organisme (0 pour la racine) . commentaires |
| Ligne 51: | Ligne 58: |
| * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' |
Table organismes_extra:: . id_organisme . variable . valeur |
| Ligne 58: | Ligne 63: |
| == Table organismes_extra == | 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. |
| Ligne 60: | Ligne 65: |
| * '''id_organisme''' * '''variable''' * '''valeur''' |
Table fonction:: . id . nom . commentaires |
| Ligne 64: | Ligne 70: |
| Table fonction_extra:: . id_fonction . variable . valeur |
|
| Ligne 65: | Ligne 75: |
| = La suite ne fait pas partie de la proposition de Thomas ;) = . 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 : . 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. == 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 defauts_groupes_extra == * '''id_groupe''' * '''id_variable''' * '''id_defaut''' (ou : on pourrait ajouter cette colonne dans la table '''groupes_extra''') 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 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.
Les utilisateurs
- Table utilisateurs
- id
- login
- mot_de_passe
- courriel
- nom
- 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.
- Table abonnements
- id_utilisateur
- id_groupe
- date_debut
- date_fin
- 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
- 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
- id_fonction
- variable
- valeur
- Table utilisateur_organisme_fonction
- id_utilisateur
- id_organisme
- id_fonction
- commentaires