3.4.1b - Ressource modérée - Mail acceptation / refus non envoyé

Bonjour

Nous avons effectué des tests avec la 3.4.1b - installation sans base de donnée reprise.

Conf Mail Auto : OK
Conf SMTP via serveur Exchange
Mail Test OK

Utilisateur
Création de réunion.
Réception "GRR : avis Ressource 1 - 2020/02/14 - Réservation en attente de modération" : OK

Connexion avec un compte permettant de modérer la ressource :
Validation

Utilisateur
Pas de réception d'emails de confirmation ni de refus.

---

Du coup, on a vu la fonction send_mail dans functions.inc.php qui définis selon les cas les emails à envoyer.

Et dans view_edit.php la gestion des modérations.
Mais on a du mal à trouver où cela pourrais coincer.

Bonjour,
à vrai dire, le comportement des mails de signalement est assez erratique. Je cherche à voir comment stabiliser cela.
Cordialement,
YN

Si j'ai bien compris, vous validez la réservation en passant par la page view_entry.php ?
Si tel est le cas, j'avais noté ce bug : la validation des réservations sur ressources modérées ne fonctionne pas.
C'est dans la to-do list. Désolé pour le dérangement.
YN

Bonjour Yan

Exactement
bah si tu l'as identifié, et si tu as un début de piste sur la fonction appelée, je peux essayer de débugger cela .

En mode "Rustine" le temps de résoudre plus durablement cela.

Olivier

C'est "tout simplement" view_entry qui ne fait pas appel à la page validation.php.
Il faut voir comment passer les paramètres à la page de validation, etc.
Merci par avance pour ton aide si tu en as le temps.
Cordialement,
YN

Voici mon analyse :
- lors d'une acceptation ou refus d'une réservation à modérer, view_entry.php s'appelle avec l'input "moderate" validé,
- moderate_entry_do() est alors appelée
- celle-ci appelle alors send_mail avec le paramètre $action à 6, ce qui déclenche l'envoi du mail avec pour adresse d'expéditeur $user_mail.

Tout cela semble correct et en local j'ai bien les mails qui arrivent, pas toujours dans l'ordre des opérations
à noter que j'utilise un serveur SMTP externe qui accepte de relayer les messages, même si l'expéditeur n'a pas une adresse dans son domaine. Cela peut être une source de blocage.

Pour que le contenu des mails soit correct sur le point des adresses de validation ou de consultation, il est nécessaire de renseigner l'adresse complète de GRR dans la page de configuration générale (typiquement https://mondomaine/GRR/).

J'ai aussi fait quelques modifications cosmétiques dans les scripts, que je dépose sur Github de suite.

Hello Yan

Alors j'ai fait des tests.
Et tu as tout à fait raison. et ca marche nickel.

Le hic, est que dans mon environnement on utilise Office365 qui ne permet pas au compte qui émet l'email (via SMTP) d'envoyer des mails aux noms d'un autres (contrainte de traçabilité / sécurité) .

Donc, pour moi tout est bon.
Je vais juste customiser l'émetteur en forçant
Settings::get("grr_mail_from")

En tout cas merci pour ton aide

Bonjour,
dans ce cas, je me demande s'il ne serait pas plus pertinent de renseigner le champ ReplyTo avec le mail de l'utilisateur, en laissant From à la valeur du compte autorisé sur le serveur SMTP.
Qu'en pensez-vous ?
Cordialement,
YN

Hello

Si tu parles de :
Dans la fonction Email de mail_class.php
Tu définis le
addReplyTo($DE, 'GRR') et là tu change le 'GRR' en 'GRR' + "Nom Utilisateur"

Dans notre contexte, nous n'en voyons pas l’intérêt

Mais ce n'est pas idiot dans d'autres contexte.

Je pensais à découpler la définition de l'expéditeur setFrom($DE,'GRR') et celle de l'adresse de réponse addReplyTo($DE,'GRR')
ce qui amène à modifier la fonction Envois, mais si cela peut améliorer le fonctionnement des mails automatiques, cela vaut la peine.