Emails bloqués en file d'attente

Hello le forum dokos :waving_hand:,

J’ai un souci d’envoi de mail sur un site.

J’ai paramétré un compte mail microsoft m365 (et c’était une sacré galère). L’envoi de mail fonctionne bien : je peux déclencher l’envoi des emails bloqués dans la queue manuellement.
Je peux aussi déclencher la méthode frappe.email.queue.flush qui envoie bien tout comme il faut.

Il semble que la tâche de fond soit bloquée (l’heure de prochaine execution indique 9:08 mais la capture d’écran a été prise à 18:22)

Avez-vous une idée de ce qui pourrait bloquer ?

Pour info le site est hébergé sur le cloud dokos.

Merci,
Antoine.

Bonjour @Antoine_Maas,

Ah oui, c’est le « problème Â» classique des sites « dormants Â», c’est-Ă -dire des sites oĂą il y a peu d’activitĂ© de connexion. C’est ce paramètre lĂ  qui est en cause :

Les sites sont mis en mode « dormant Â» après 4 jours consĂ©cutifs sans connexion. Or, on se connecte rarement au site si la session dure longtemps. Donc le site s’endort alors mĂŞme qu’on l’utilise quotidiennement.


Je me suis connectĂ© sur ton site donc le planificateur a dĂ» redĂ©marrer par lui-mĂŞme. Je t’invite Ă  ajuster la valeur du champ pour mettre « 999999 Â». Il faut vraiment qu’on trouve une solution plus intelligente dĂ©tecter l’activitĂ© d’un site que juste les logins/logouts…

En allant dans la liste des Journal des tâches de fonds programmées on remarque effectivement que ça fait quelques jours que les tâches sont lancées une fois par jour (ici on voit qu’on passe abruptement de avant-hier à hier).

Corentin

2 Likes

Pour ceux qui liraient ce post plus tard, la doc suivante est exhaustive.
En la suivant A LA LETTRE, ça fonctionne bien:

3 Likes

Merci @corentin pour la réponse j’aurai jamais trouvé seul :exploding_head:

Je trouve ce paramètre plutôt pertinent mais il suffirait de mettre la valeur par défaut à 7. Car par défaut je crois que les sessions se deconnectent pendant le weekend (sauf pour ceux qui aiment faire du dokos le dimanche) ? Sinon on perd ça avec une deconnection après 48h

A plus,
Antoine.

Par contre tout mes contrats de réservations de ressources sont passés en terminés (ils étaient en attente, en brouillon et actif selon les).

A cause de la méthode bookings.bookings.doctype.booking_contract.booking_contract.update_contracts_status?

Je pense qu’il s’agit d’un bug dont voici une proposition de fix : fix: Do not terminate permanent contract when updating status (!369) · Requêtes de fusion · Dokos / Dokos Bookings · GitLab

1 Like

Vous avez une idée de solution pour remettre les contrats sur leur statuts précédent ?
Je sais pas si y aurait un flag « previous_status Â» que je pourrais aller chercher sur la console système ?

A part restaurer un backup entier.

Non il n’y a pas de champ comme ça malheureusement.

L’ancien statut est forcément parmi :

  • Amended (si le document est liĂ© Ă  un second Contrat qui l’amende)
  • Active (sinon si docstatus = 1 et qu’il a Ă©tĂ© signĂ©, voir champ signatory)
  • Pending Signature (sinon si docstatus = 1 et qu’il est liĂ© Ă  une Communication envoyĂ©e par e-mail)
  • Pending (sinon si docstatus = 1)
  • Draft (sinon si docstatus = 0)

Merci @corentin, j’ai pu corrigé le souci facilement depuis la console système avec ta logique :folded_hands:

Merci :+1:
Atntoine.

1 Like