Ne récupère pas les mails

[kboissier]

Bonjour,

Gestsup 3.2.5 est installé chez nous depuis Février 2021 et fonctionne très bien.

Ce matin, nous avons reçu 43 nouveaux tickets d'un coup (nous sommes environ entre 10 et 15 tickets par jour habituellement). Ils ont tous été envoyés à 4h49 du matin alors que les mails avaient été envoyés tout au long de la journée d'hier.
Et depuis cette réception 43 tickets d'un coup, plus aucun ticket n'arrive. Nous avons vérifié que les mails arrivaient bien sur la boite mails et effectivement c'est le cas.

J'ai essayé de modifier l'adresse du serveur de outlook.office365.com en mail.office365.com, mais ça n'a rien changé.
J'ai vérifié les paramètres SMTP configurés dans Gestsup sur un client mail classique, et je récupère bien les mails.
J'ai tenté de passer en version 3.2.6 (installation faite avec succès) mais ça n'a pas réglé le problème.

Lorsque je lance mailtoticket.php depuis une page Web j'obtiens cela


Dans les logs de securité il y a une alerte à l'heure où tous les tickets ont été créés:
IMAP connector : blacklisted file "Avis de paiement.html" blocked, ticket 2242

Dans les logs d'apache, la seule erreur que j'ai trouvé est postérieure au problème et ne semble pas correspondre à mon problème:
[Thu Jun 03 07:42:38.191043 2021] [:error] [pid 31163] [client 93.9.242.235:33700] PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error' in /var/www/html/gestsup/core/auto_close.php:19\nStack trace:\n#0 /var/www/html/gestsup/core/auto_close.php(19): PDOStatement->fetch()\n#1 /var/www/html/gestsup/core/cron_daily.php(21): require('/var/www/html/g...')\n#2 /var/www/html/gestsup/index.php(298): require('/var/www/html/g...')\n#3 {main}\n thrown in /var/www/html/gestsup/core/auto_close.php on line 19

Avez-vous une idée d'où cela peut provenir?

Un grand merci d'avance.

[Flox]

Bonjour,

merci d'installer la dernière version stable de l'application 3.2.10, puis réessayer.
Si le problème persiste :
- Activer le mode debug de l'application, puis lancer une récupération des mails depuis le connecteur IMAP et transmettre un impression écran du résultat.
- Transmettre un impression écran de la page Administration > Système.

Cdt

[kboissier]

Petite précision: Nous avons un deuxième dossier (gestsupmg) sur le même serveur dans /var/www/html/ mais connecté à une bdd différente bien évidemment.

Les 2 Gestsup ont été installés à 1 semaine d'intervalle, et fonctionnent de la même manière pour la récupération des mails pour création des tickets. Ce deuxième site Gestsup continue de fonctionner à la perfection.

Sauf erreur de ma part, aucune modification sur le serveur que ce soit au niveau d'apache, php, mysql, ni même au niveau du dossier Gestsup ou de la configuration Gestsup, n'a été effectué dernièrement.

[Flox]

Bonjour,

merci d'installer la dernière version stable de l'application 3.2.10, puis réessayer.
Si le problème persiste :
- Activer le mode debug de l'application, puis lancer une récupération des mails depuis le connecteur IMAP et transmettre un impression écran du résultat.
- Transmettre un impression écran de la page Administration > Système.

Cdt

[kboissier]

Merci de votre retour.

J'ai installé la 3.2.10 après avoir sauvegardé la BDD et le dossier de la 3.2.6.
Lorsque je me suis connecté il m'a affiché un Gestsup complètement vide... Et pourtant le connect.php a bien les informations de la BDD.
J'ai remis le dossier sauvegardé de ma 3.2.6, mais il m'affiche toujours une version 3.2.10 quelque soit le navigateur (4 navigateurs sur PC et 2 navigateurs mobile).

Je n'ai donc pas la possibilité d'afficher le debug.

Merci de votre aide précieuse

[Flox]

Si vous souhaitez faire une restauration, il est nécessaire de restaurer les fichiers et la base de données, cf documentation.

Concernant le défaut "Vide" sur la version 3.2.10, vous pourrez activer le mode debug de l'application, avec la requête suivante :

Code : Tout sélectionner

UPDATE `tparameters` SET `debug`='1'; 

Ou bien consulter les logs d'erreur Apache dans /var/log/apache2/error.log

Cdt

[kboissier]

Après moultes galères et tests, j'ai fini par migrer mon installation Gestsup sur un autre serveur (migration prévue d'ici quelques semaines) et la récupération des mails a fonctionné. Il devait y avoir un problème avec php_imap je suppose.
J'ai mis également mis du temps à comprendre le lien étroit entre la version installée qui doit être identique à celle définie dans la BDD.

Maintenant tout est OK pour pour moi.

Merci pour votre réactivité

[kboissier]

Bonjour,

Je me permets de faire un up sur mon message d'hier. Après avoir migré sur une version 3.2.10 (3.2.5 mis à jour en semi-auto depuis l'application) avec un serveur debian 10 tout neuf et donc une installation à jour (voir PJ "Système"), je retrouve mon problème de base:

A savoir que le serveur ne récupère plus les mails ("0 mail received" alors qu'il y a bien des mails non lus dans le INBOX du compte Office365). Ce matin tout était parfait, et le serveur récupérait bien les mails que ce soit en ligne de commande "/usr/bin/php7.3 /var/www/html/gestsupmg/mail2ticket.php" ou depuis le bouton "Lancer l'import des mails".

J'ai donc planifié un crontab pour exécuter la commande pour mail2ticket.php toutes les minutes. J'ai l'impression que c'est depuis ce moment là que, même en lançant la commande à la main ou depuis le bouton d'import, l'import ne se fait plus (voir PJ "mail2ticket.jpg"). J'ai modifié le cron pour qu'il s'exécute toutes les 5 minutes mais le problème est le même

Il n'y pas d'erreur PHP dans error.log et le cron s'exécute bien à l'intervalle demandé lorsqu'on regarde le syslog.

Là je sèche complètement. Auriez-vous une idée du problème? Linux, PHP, Gestsup, Office365????

Merci d'avance de votre aide

[Flox]

Pouvez-vous transmettre un impression écran de la configuration de votre connecteur IMAP.

Vous pourrez tester de modifier le dossier Inbox et tester avec un autre serveur de messagerie pour test.

[kboissier]

Bon, les dernières nouvelles:

Je pense que le connecteur est bien configuré (je vous mets en PJ un screen à toutes fins utiles) et que le serveur Office365 n'aime pas les requêtes trop régulières. Il y a environ 20mn j'ai totalement arrêté le cron. Je viens juste de relancer la commande manuellement et 17 tickets viennent de remonter (par contre mail2ticket semble souffrir quand il en récupère autant).

Je viens de modifier le cron pour lancer mail2ticket.php toutes les 10mn... à suivre.

Merci encore pour votre disponibilité.