Hello le forum dokos
,
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 
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?
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 
Merci 
Atntoine.
1 Like