Re: [Devel] Besoin pour l'AdL

["David MENTRE" <dmentre AT linux-france.org>]

Salut Thomas,

C'est l'été et tu te lances dans les travaux d'infrastructure ? :-)

2008/6/30 Thomas Petazzoni <thomas.petazzoni AT enix.org>:
> Mais étant donné qu'il y a un tel besoin
> pour Toulibre, je suppose que d'autres associations peuvent avoir un
> besoin similaire (je pense par exemple à toutes celles qui ont des
> rendez-vous réguliers, comme Gulliver, Chtinux, Parinux).

Tu supposes bien. :-)

> Une solution est de générer un hash aléatoire associé à chaque
> évènement, ce hash étant envoyé au soumetteur de l'évènement quand
> celui-ci est validé et stocké dans la base de données. Il sert de «clé
> secrète» pour pouvoir éditer l'évènement après modération. Le mail de
> validation d'évènement contient un lien direct vers un script auquel
> cette clé secrète est passée en paramètre, ainsi que le numéro de
> l'évènement. Le soumetteur de l'évènement accède ainsi à un formulaire
> pour modifier l'évènement. Quelques questions se posent néanmoins :
>
>  * Est-ce suffisamment sûr ?

Suffisamment en tout cas pour l'AdL si le hash est bien aléatoire
(/dev/urandom marche très bien pour ça).

>  * La modification d'un évènement par le soumetteur doit-elle faire
>   l'objet d'une nouvelle modération, ou alors peut-on laisser le
>   soumetteur modifier directement l'évènement et travailler par
>   modération a posteriori. Je serai tenté de dire qu'une modération a
>   posteriori serait suffisante:

Itou.

> le filtrage en terme de ligne
>   éditoriale intervient lors de la validation initiale de l'évènement.
>   Pour les typos, on peut tolérer qu'elles soient présentes quelques
>   heures avant qu'un modérateur ne s'en occupe. Quel est votre avis ?

Vu la qualité que tu veux, il faut une re-validation. La description
initiale peut être très succinte ("qqch autour du libre" ;-). Mais ça
risque d'être trop lourd. Donc le a priori me semble un bon compromis.

Côté technologie, tu peux imaginer que les modérateurs aient un flux
RSS des modifs et jette un coup d'oeil en positionnant un flag "revu
et ok" quelque part une fois la relecture faite.

>  * L'annulation d'un évènement. Si Toulibre rentre en début d'année
>   tous ses évènements puis finalement que l'un d'entre eux est annulé.
>   Comment gérer ça ? Prévoir un autre script utilisant la même clé
>   secrète, mais permettant d'annuler ?

Ou tout simplement avoir *une* clé qui donne accès au panneau de
contrôle de l'événement. Et dans le panneau tu peux annuler, modifier,
déplacer, etc.

> Faut-il supprimer tout
>   simplement l'évènement, ou le garder avec la mention «Annulé» ?

Les deux mon capitaine ! :-) Si c'est vraiment en avance, c'est plus
simple d'effacer sans trace, ça ne pollue pas l'agenda. Mais si c'est
annulé à la dernière minute, il vaut mieux afficher en barré et
[annulé] dans l'agenda, pour que les gens s'en rendent compte. Seul
l'organisateur de l'évènement peut choisir entre les deux options.

Amicalement,
d.