Project

General

Profile

Development #89284

Permettre que les emails d'une même demande soient dans le même fil en se répondant

Added by Yann Weber about 1 month ago. Updated 20 days ago.

Status:
Solution déployée
Priority:
Normal
Assignee:
Target version:
-
Start date:
09 April 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

L'idée serait de stocker l'EmailEvolutionPart, en y ajoutant le message-id.
Lors de l'envoie d'un email, si un EmailEvolutionPart est présent on récupère le message-id pour le mettre en Reply-To.

Comportement en feature flag, étant donné qu'on n'est pas certain du comportement sur différents clients mails,


Files

deux-messages-même-message-id-même-references.png (9.16 KB) deux-messages-même-message-id-même-references.png avec des messages qui ont tous le même message-id et le même references Frédéric Péters (de retour le 27 mai), 09 April 2024 03:27 PM
deux-messages-même-references-vers-message-id-non-existant.png (9.38 KB) deux-messages-même-references-vers-message-id-non-existant.png avec uniquement des messages qui pointent un message-id qui n'existe pas Frédéric Péters (de retour le 27 mai), 09 April 2024 03:27 PM
deux-messages-references-autre.png (9.2 KB) deux-messages-references-autre.png le deuxième message qui References: le premier Frédéric Péters (de retour le 27 mai), 09 April 2024 03:29 PM

Associated revisions

Revision ea2ab5c7 (diff)
Added by Yann Weber 20 days ago

emails: add Message-Id, In-Reply-To and References headers (#89284)

Revision af25e206 (diff)
Added by Yann Weber 20 days ago

emails: fix tests to allow simple hostname fetch in sendmail (#89284)

History

#1

Updated by Thomas Noël about 1 month ago

Note : ne pas utiliser Reply-To (il ne faut pas laisser penser qu'on peut "répondre" à ce genre de courriel).

Plutôt utiliser l'entête « References », par exemple de la forme publik-formdata-{{ form_number }}.{{ form_receipt_datetime }}@{{ server }} (sur exemple des entêtes redmine)

(et pas besoin de EmailEvolutionPart)

#2

Updated by Frédéric Péters (de retour le 27 mai) about 1 month ago

Ça a du être un mauvais copié/collé dans la discussion c'était "In-Reply-To" (qui pointe un message id); mais "References" est plus simple comme entête, peut être utilisé.

(et pas besoin de EmailEvolutionPart)

Perso j'aurais pensé que oui, pour référencer le message initial. (redmine s'en sort parce que le message initial, de création de ticket, produit un message-id d'un format différent des messages "réponse au ticket").

#3

Updated by Thomas Noël about 1 month ago

Frédéric Péters a écrit :

(et pas besoin de EmailEvolutionPart)

Perso j'aurais pensé que oui, pour référencer le message initial. (redmine s'en sort parce que le message initial, de création de ticket, produit un message-id d'un format différent des messages "réponse au ticket").

En fait je ne sais pas trop comment fonctionnent les lecteurs de mail des humain, mais le mien se fiche d'avoir le mail originel (le premier du fil) : il regroupe dans un seul fil tous les mails qui ont le même « References ». J'imagine que c'est pareil sur les autres MUA, parce qu'on a le droit de supprimer le premier mail d'une discussion, ça ne doit pas casser le fil. Je pense donc qu'on peut faire ça tranquillement : poser toujours le même Reference à tous les mails issus d'une même demande.

C'est pour ça que je vois pas l'utilité de jouer avec des EmailEvolutionPart.

#4

Updated by Yann Weber about 1 month ago

Frédéric Péters a écrit :

Ça a du être un mauvais copié/collé

C'est exactement ça, navré.

Je suis allé jeter un oeil dans un vieux projet ou j'avais fait des tests à ce propos. J'avais finis par utiliser les deux entêtes :
  • In-Reply-To qui référence le Message-Id auquel on répond
  • References une liste de Message-Id formant le fil/thread

J'imagine que je m'étais basé sur cette section de la RFC 2822 :
https://www.rfc-editor.org/rfc/rfc2822#section-3.6.4

Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below.

Ca vous semble une bonne solution ?

#5

Updated by Benjamin Dauvergne about 1 month ago

Que ce soit stocké ou générer à la volée j'aime bien le format proposé par Thomas, logger au niveau du serveur de mail ce serait pratique pour savoir l'origine des mails (et authentic devrait faire pareil).

#6

Updated by Yann Weber about 1 month ago

Thomas Noël a écrit :

poser toujours le même Reference à tous les mails issus d'une même demande.

J'imagine que ça doit fonctionner (regrouper tout les messages dans un même thread), mais, si je comprend bien la RFC, le MUA va considérer que tout les mails sont des réponses au même mail d'origine :

https://www.rfc-editor.org/rfc/rfc2822#section-3.6.4

The "References:" field will contain the contents of the parent's "References:" field (if any) followed by the contents of the parent's "Message-ID:" field (if any).

Mais c'est peut être pas dérangeant pour la fonctionnalité en question ?

Dans ce cas j'imagine que la meilleur manière de faire serait de mettre le même Message-Id dans References et In-Reply-To.

#7

Updated by Frédéric Péters (de retour le 27 mai) about 1 month ago

Plutôt utiliser l'entête « References », par exemple de la forme publik-formdata-{{ form_number }}.{{ form_receipt_datetime }}@{{ server }} (sur exemple des entêtes redmine)

Les Message-ID doivent être unique. Comme noté à propos de redmine, pour une réponse à un ticket on a :

Message-ID: <redmine.journal-543263.20240409130840@entrouvert.com>   <-- unique, référence à la note
References: <redmine.issue-89284.20240409085244@entrouvert.com>      <-- le message-id du message "nouveau ticket" 

Comme on n'a pas de trucs en dur, il faut pour moi que le message-id soit stocké (au moins pour le premier mail, mais autant pas faire de distinction), pour ensuite pouvoir être référencé via l'entête References (ou In-Reply-To) des mails suivant.

wcs-{{ "formdata" ou "carddata" }}-{{ formdef.id }}-{{ formdata.id }}.{{ now|date:"Ymd.His.u" }}@tenant

(cf captures attachées pour les différents rendus de combinaisons dans mutt)

#8

Updated by Robot Gitea about 1 month ago

  • Status changed from Nouveau to En cours

Yann Weber (yweber) a ouvert une pull request sur Gitea concernant cette demande :

#9

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée
#10

Updated by Robot Gitea about 1 month ago

  • Status changed from Solution proposée to En cours

Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#11

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée
#12

Updated by Robot Gitea about 1 month ago

Yann Weber (yweber) a demandé une relecture de Frédéric Péters (fpeters) sur une pull request sur Gitea concernant cette demande :

#13

Updated by Robot Gitea about 1 month ago

  • Status changed from Solution proposée to En cours

Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#14

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée
#15

Updated by Robot Gitea about 1 month ago

Yann Weber (yweber) a demandé une relecture de Frédéric Péters (fpeters) sur une pull request sur Gitea concernant cette demande :

#16

Updated by Robot Gitea about 1 month ago

  • Status changed from Solution proposée to En cours

Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#17

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée

Yann Weber (yweber) a demandé une relecture de Frédéric Péters (fpeters) sur une pull request sur Gitea concernant cette demande :

#18

Updated by Robot Gitea 24 days ago

  • Status changed from Solution proposée to Solution validée

Frédéric Péters (fpeters) a approuvé une pull request sur Gitea concernant cette demande :

#19

Updated by Robot Gitea 20 days ago

  • Status changed from Solution validée to Résolu (à déployer)

Yann Weber (yweber) a mergé une pull request sur Gitea concernant cette demande :

#20

Updated by Transition automatique 20 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF