Development #89284
Permettre que les emails d'une même demande soient dans le même fil en se répondant
0%
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,
Fichiers
| deux-messages-même-message-id-même-references.png (9,16 ko) 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 | ||
| deux-messages-même-references-vers-message-id-non-existant.png (9,38 ko) deux-messages-même-references-vers-message-id-non-existant.png | avec uniquement des messages qui pointent un message-id qui n'existe pas | ||
| deux-messages-references-autre.png (9,2 ko) deux-messages-references-autre.png | le deuxième message qui References: le premier |
Historique
Mis à jour par Thomas Noël il y a 20 jours
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)
Mis à jour par Frédéric Péters il y a 20 jours
Ç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").
Mis à jour par Thomas Noël il y a 20 jours
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.
Mis à jour par Yann Weber il y a 20 jours
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-Toqui référence leMessage-Idauquel on répondReferencesune liste deMessage-Idformant 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 ?
Mis à jour par Benjamin Dauvergne il y a 20 jours
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).
Mis à jour par Yann Weber il y a 20 jours
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.
Mis à jour par Frédéric Péters il y a 20 jours
- Fichier deux-messages-même-message-id-même-references.png deux-messages-même-message-id-même-references.png ajouté
- Fichier deux-messages-même-references-vers-message-id-non-existant.png deux-messages-même-references-vers-message-id-non-existant.png ajouté
- Fichier deux-messages-references-autre.png deux-messages-references-autre.png ajouté
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)
Mis à jour par Robot Gitea il y a 19 jours
- Statut changé de Nouveau à En cours
Yann Weber (yweber) a ouvert une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/wcs/pulls/1391
- Titre : WIP: emails: add Message-Id, In-Reply-To and References headers (#89284)
- Modifications : https://git.entrouvert.org/entrouvert/wcs/pulls/1391/files
Mis à jour par Robot Gitea il y a 19 jours
- Statut changé de Solution proposée à En cours
Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :
Mis à jour par Robot Gitea il y a 18 jours
Yann Weber (yweber) a demandé une relecture de Frédéric Péters (fpeters) sur une pull request sur Gitea concernant cette demande :
Mis à jour par Robot Gitea il y a 18 jours
- Statut changé de Solution proposée à En cours
Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :
Mis à jour par Robot Gitea il y a 14 jours
Yann Weber (yweber) a demandé une relecture de Frédéric Péters (fpeters) sur une pull request sur Gitea concernant cette demande :
Mis à jour par Robot Gitea il y a 14 jours
- Statut changé de Solution proposée à En cours
Frédéric Péters (fpeters) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :
Mis à jour par Robot Gitea il y a 14 jours
- Statut changé de En cours à 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 :
Mis à jour par Robot Gitea il y a 3 jours
- Statut changé de Solution proposée à Solution validée
Frédéric Péters (fpeters) a approuvé une pull request sur Gitea concernant cette demande :