Bonjour,
nous pensons avoir localisé le(s) problème(s). En effet, tu as raison Séverin, ça semble en relation avec MDL-59909.
Je reviens rapidement sur le délai de délivrance des courriels:
nous avons testé en créant sur des forums de cours en ajoutant des messages. Nous ne recevions aucune notification. Dés que nous avons reçu le rapport "État des sauvegardes planifiées" (émis lorsque la tâche est fini), nous avons reçu toutes les notifications d'un coup. Et pour le reste de la journée, dès qu'on ajoutait d'autres messages aux forums, nous recevions les notifications dans les 2 mins suivantes.
Mais peut-être que cela vient de notre serveur.
Sans savoir pourquoi, nous avons des lignes dans la table {assign} (des Devoirs) qui n'ont pas de name (ce champ ne devrait pas être vide puisque obligatoire). Ces devoirs "fantômes" provoquent un crash du script de la tâche adhoc core\task\refresh_mod_calendar_events_task au moment où elle effectue "Refreshing events for assign".
Une fois ces lignes supprimées, le script poursuivit avec les autres modules :
Refreshing events for assign Refreshing events for assignment Refreshing events for book Refreshing events for chat Refreshing events for choice Refreshing events for data Refreshing events for feedback Refreshing events for folder Refreshing events for forum Refreshing events for glossary Refreshing events for imscp Refreshing events for label Refreshing events for lesson Refreshing events for lti Refreshing events for page Refreshing events for quiz Refreshing events for resource Refreshing events for scorm Refreshing events for survey
Malgré que le module mod_survey soit désactivé, ce script le traite aussi.
En DB, on a 5 lignes dans la table {survey}, et toutes ont 0 dans le champ course.
De fait, le script crash à nouveau. Ce qui rejoint la description de MDL-59909.
Une fois ces problèmes éliminés, le script se termine correctement. La tâche est alors supprimée de la table {task_adhoc}.
Petit changement sur notre fonction précédente:
il ne faut pas comparer userid.
Il est fixé à 0 dans $event, mais s'il est 0 en DB, calendar_event::load() le défini à $USER->id (id de l'utilisateur courant).