3192
Commentaire: + URL
|
4288
procédure pour l'édition collaborative
|
Texte supprimé. | Texte ajouté. |
Ligne 3: | Ligne 3: |
== Ça concerne quoi ? == Du trivial au complexe (pas seulement pour des raisons techniques) : * l'agenda des vacances AuF par pays ou peut-être plutôt par région * l'agenda des missions par personne (accès à restreindre à l'interne ? ou sinon remplir en plus l'agenda de (in)disponibilité) * l'agenda des évènements par pays ou même par région vu le volume raisonnable => il faudrait le produire à partir des saisie sur l'Intranet afin d'éviter la double-saisie * l'agenda des (in)disponibilités par personne (sans préciser les raisons, question de respect de vie privée) => partir du tableau des absences/congés géré dans chaque implantation |
|
Ligne 37: | Ligne 45: |
Et voilà ! Ça suffit pour être opérationnel !! :-) |
|
Ligne 42: | Ligne 52: |
== Conclusion == Et voilà ! Ça suffit pour être opérationnel !! :-) |
== Notes de procédure == |
Ligne 51: | Ligne 59: |
Si on veut absolument faire de l'édition collaborative d'agenda il faut impérativement respecter la procédure suivante : * cliquer sur actualiser avant la moindre modification * modifier tout de suite après l'actualisation * le temps entre l'actualisation et la modification est la période de risque : si quelqu'un modifie dans la même période, '''l'une des deux modifications sera perdue''' |
Quelques notes sur mes expérimentations de gestion d'agenda en ligne.
Ça concerne quoi ?
Du trivial au complexe (pas seulement pour des raisons techniques) :
- l'agenda des vacances AuF par pays ou peut-être plutôt par région
- l'agenda des missions par personne (accès à restreindre à l'interne ? ou sinon remplir en plus l'agenda de (in)disponibilité)
l'agenda des évènements par pays ou même par région vu le volume raisonnable => il faudrait le produire à partir des saisie sur l'Intranet afin d'éviter la double-saisie
l'agenda des (in)disponibilités par personne (sans préciser les raisons, question de respect de vie privée) => partir du tableau des absences/congés géré dans chaque implantation
Côté client
Utiliser le [http://www.mozilla.org/projects/calendar/lightning/ projet Lightning] de Mozilla. Pour cela il suffit d'installer le greffon [https://addons.mozilla.org/fr/thunderbird/addon/2313 Lightning] pour Thunderbird.
Bien suivre les instructions pour l'installer dans Thunderbird et non dans Firefox !
Dans Thunderbird, aller dans le menu Fichier / Nouveau / Agenda..., choisir Sur le réseau au format iCalendar (ICS)FootNote(Google utilise le même !) et indiquer l'URL de l'agenda, par exemple http://www.vn.auf.org/webdav/vacances-vietnam.ics pour connaître les dates officielles (AuF) des vacances au Vietnam.
Côté serveur
Accéder aux agendas des autres c'est bien beau, mais créer les siens c'est encore mieux ! Hé bien là aussi c'est simple, ou disons plutôt pas compliqué...
Il faut installer un Apache avec le support WebDAV, c'est à dire une version 2.0 ou supérieure. Ensuite il faut justement activer les modules qui conviennent, simplement avec sudo a2enmod dav_fs. Puis créer un dossier web, par exemple /agenda, et configurer apache pour y accéder. C'est là la seule partie sensible : il faut gérer les droits selon sa politique locale.
Voici un exemple qui permet à tout le monde de lire les agendas, mais n'autorise la modification (ici de tous les agendas, sans restriction fine) qu'après authentification :
<Directory /srv/www/agenda> Order Allow,Deny Allow from all Dav On AuthType Basic AuthName "WebDAV AuF BAP" AuthUserFile /etc/apache2/passwd <LimitExcept GET OPTIONS> require valid-user </LimitExcept> </Directory>
Et voilà ! Ça suffit pour être opérationnel !!
Publication
Il serait aussi intéressant d'offrir une visibilité web directe pour certains agenda, comme par exemple ceux présentant les évènements. Il reste donc à étudier quelques outils comme [http://www.k5n.us/webcalendar.php webcalendar] ou [http://phpicalendar.net/ phpicalendar], non pas pour de la saisie mais juste pour de la mise en ligne web.
Notes de procédure
Ensuite se pose le problème de la gestion de ces agendas et en particulier des accès concurrents. Mais ce problème n'en est pas forcément un si on respecte quelques règles simples :
- tout agenda ne doit être modifié que par une seule personne qui sera responsable de sa mise à jour, avec éventuellement une personne suppléante tant que cette dernière ne le modifie pas en même temps
- on découpera les agendas par domaine distinct, voir aussi par personne, afin de pouvoir respecter la première règle
- on installera tous les agendas utiles chez les utilisateurs en les laissant choisir ceux à afficher simultanément, ce que Lightning permet de faire par des simples cases à cocher dans la liste des agendas
Si on veut absolument faire de l'édition collaborative d'agenda il faut impérativement respecter la procédure suivante :
- cliquer sur actualiser avant la moindre modification
- modifier tout de suite après l'actualisation
le temps entre l'actualisation et la modification est la période de risque : si quelqu'un modifie dans la même période, l'une des deux modifications sera perdue
Notes :