[Epnadmin-fr] EPNadmin 0.8 :: Gestion du temps (Calendar)

[Marc C]

Bonjour

J'essaye de définir la direction à prendre pour le développement de la gestion 
du temps au sein d'EPNadmin. J'ai observé l'application du point de vue du 
temps, en voici le résumé :

Les parties de l'application concernées par la gestion du temps :

- accès individuel [usager + poste + créneau horaire ]

- session [initiation + animateur + salle ou postes + créneau horaire]

- prêt [ liste d'équipements + date début prévu et réel, fin prévu et réel ]

- ouverture salle [ salle + créneau horaire d'ouverture ]

- activité animateur [animateur + activité + créneau horaire ]

- avancement projet [ projet + avancement + salle/postes + créneau horaire]


L'implémentation actuelle consiste en une table dediée à la planification de 
chacune de ses tâches (room_calendar, session, facilitator_calendar).



Afin de faire évoluer l'application que pensez vous d'avoir :

a. une table commune Calendar 
(solution proposée dans mon mail précédent "Calendar/Planning")

Une table centrale dans laquelle on ajoute des événements en spécifiant : 
identifiant unique, date heure de debut, durée et type de  l'événement.

Des tables liant le calendrier et les types d'événement, par exemple :
. la table session ne comporterait plus les informations de temps mais 
seulement l'identifiant unique de l'événement planifier.
. une table acces_individuel sera créer comportant l'identifiant usager, celui 
du poste utilisé et celui de l'événement.

Avantages :
- une table contenant tous les événements, identifié par type
- une interface (utilisateur et développeur) générique pour la planification 
des événements

Inconvénient :
- les types d'événements doivent être bien définie, par exemple pour le prêt 
d'équipement il devrait y avoir 4 types d'événement : pret_debut_prevu, 
pret_debut_reel, pret_fin_prevu et pret_fin_reel.



b. une table dediée à chaque partie

Nous gardons la structure SQL existante et continuons de l'appliquer pour 
chaque module ajouté, mais ces tables devront avoir la même structure afin de 
pouvoir utiliser des outils identiques( formulaire pour les utilisateurs et 
fonctions pour les développeurs).

Avantage :
- indépendance des modules pour la gestion du planning

Inconvénient :
- redondance des tables, n tables pour n modules

pgpwZTI5PbZ11.pgp
Description: PGP signature