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

[Dayot Loïc]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dans l'état des lieux, il manque ce qui existe déjà 
- - maintenance (date incident, échéance, date de réponse, animateurs 
(dépanneurs), temps de résolution de maintenance)
et ce qui arrivera un jour :
- - disponibilité des usagers

C'est vrai que l'aspect modulaire est à conserver dans l'application. Alors 
entre les deux solutions (centralisé ou modulaire et redondant), je ne sais 
pas ce qui est le mieux.

Cela dit, je trouve qu'il y a une différence dans les relations aux temps 
entre la disponibilté et l'utilisation d'une ressource ou d'une personne. 
Est-ce que dans le deux solutions, cette distinction fonctionnelle est 
possible ?

Loïc.




Le lundi 25 Octobre 2004 17:39, Marc C a écrit :
> 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

- -- 

Hébergeur hébergé http://ouvaton.coop
Alternative logiciel libre http://april.org
2 CV anciennes sur http://amis2cv.org
Se souvenir du Maroc http://marocamnesie.com
Imaginez la suite...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBfWAbN/RN38XtBQkRAuoJAJ98Fw48FsLsUbMCppBlxB8x0TA4kgCfd8Wx
Vx8uFU+/kmhGPJZYR4iK2wk=
=rtCR
-----END PGP SIGNATURE-----