Produits Entr'ouvert » Chrono

Frédéric Péters a écrit :

Est-ce vraiment utile de tourner ça toutes les 5 minutes ? (il me semble que non ?)

Il y a d'un côté le fonctionnement auquel tu penses : si un évènement récurrent est sans date de fin, on crée un an d'évènements réservables, et chaque jour un nouveau apparaît. Ici bien sûr on pourrait tourner le cron bien moins régulièrement.

Mais ce n'est pas la raison d'être du cron, qui sert en vérité à gérer les exceptions.
Dans le cas où on va ajouter une exception simple dans le backoffice pour un agenda donné, on pourrait aller tout de suite supprimer les évènements couverts, pas besoin d'asynchrone. Par contre, si les exceptions sont synchronisées depuis un ICS, ou récupérées depuis un calendrier d'indispo : alors là il faut un cron qui aille régulièrement regarder l'état des exceptions connues pour supprimer les évènements qui ne doivent pas être réservables.
C'est pour ça qu'il y a ce cron, parce qu'actuellement on ne sait pas trop quand arrivent de nouvelles exceptions.

On peut quand même réduire la fréquence (une heure c'est sûrement acceptable ?) mais il faudra quand même du code pour déclencher la mise à jour des exceptions en cas d'ajout simple, où un délai important paraîtrait bizarre (je pense qu'on avait pas les jobs uwsgi au moment où ce cron est apparu).

Est-ce qu'on pourrait faire l'ajout des nouvelles occurrences une fois par jour, et la suppression des occurrences obsolètes plus fréquemment ?
C'est à dire, splitter la méthode update_recurrences ? Ou ajouter un param ?

Non car ça se joue dans les deux sens, il faut à la fois supprimer les évènements couverts par une nouvelle exception et ajouter les évènements « découverts » lors de la suppression d'une exception. Cet ajout se fait avec la même requête qui crée les nouvelles occurrences.