Il existe plusieurs façons de lier au(x) message(s) parent(s), et l’association est stockée via la table PostReply, avec reply_post_id représentant le message qui fait la réponse et post_id faisant référence au parent. Les e-mails entrants utilisent In-Reply-To pour les lier, et depuis l’interface utilisateur de Discourse, si vous citez plusieurs messages, plusieurs enregistrements PostReply sont créés, et si vous utilisez le bouton « Répondre » sur un seul message, il est utilisé pour créer un enregistrement PostReply.
Oui, désolé, j’aurais dû le noter, add_identification_field_headers ne sera plus utilisé, tout est dans add_experimental_identification_field_headers, le nouveau code. Merci de faire des commentaires sur le code lui-même, je ne m’y attendais pas ! Je vais les examiner aujourd’hui.
@cameron-simpson mes excuses, je pense que vous avez peut-être examiné un commit antérieur dans cette PR. J’ai maintenant rebasé le code pour cela et j’ai à nouveau poussé pour avoir un seul commit avec tout le code le plus récent que nous avons testé sur ce site de test. J’espère que le message de commit est utile et logique.
Pour References, si l’utilisateur répond à un message, j’utilise la chaîne complète des Message-IDs, de l’OP jusqu’au message parent, dans l’ordre. Par exemple, si tous ces messages sont une chaîne directe de réponses :
Message 1 – discourse/post/500@test.site
Message 2 – discourse/post/501@test.site
Message 3 – discourse/post/502@test.site
Message 4 – discourse/post/503@test.site
Message 5 – discourse/post/504@test.site
Alors l’en-tête In-Reply-To pour le dernier message sera :
Si un nouveau message est créé qui ne répond pas directement au message ci-dessus, par exemple Message 6 – discourse/post/505@test.site, alors son Message-ID In-Reply-To sera <discourse/post/500@test.site> (l’OP), et References sera <discourse/post/500@test.site> qui est également l’OP.
Veuillez me faire savoir si cela est incorrect et je peux réviser.
Par Martin Brennan via Discourse Meta à 23 août 2022 23:59 :
@cameron-simpson mes excuses, je pense que vous avez peut-être examiné un commit antérieur dans cette PR. J’ai maintenant rebasé le code et poussé à nouveau pour avoir un seul commit avec tout le code le plus récent que nous avons testé sur ce site de test. J’espère que le message de commit est utile et logique.
Je vais regarder à nouveau, merci.
Pour References, si l’utilisateur répond à un message, j’utilise la chaîne complète des Message-IDs, de l’OP jusqu’au message parent, dans l’ordre. Par exemple, si tous ces messages sont une chaîne directe de réponses :
Message 1 – discourse/post/500@test.site
Message 2 – discourse/post/501@test.site
Message 3 – discourse/post/502@test.site
Message 4 – discourse/post/503@test.site
Message 5 – discourse/post/504@test.site
Cela semble correct.
Alors l’en-tête In-Reply-To du dernier message sera :
In-Reply-To: <discourse/post/503@test.site>
Et References sera
Si un nouveau message est créé qui ne répond pas directement au message ci-dessus, par exemple Message 6 – discourse/post/505@test.site, alors son Message-ID In-Reply-To sera <discourse/post/500@test.site> (l’OP), et References sera <discourse/post/500@test.site> qui est aussi l’OP.
Merci. J’ai aussi oublié de mentionner que nous devons effectivement aller dans la base de données pour recréer la chaîne References basée sur les enregistrements PostReply, vous le verrez dans le dernier commit.
@cameron-simpson Je voudrais lancer le processus de revue interne sur ce code la semaine prochaine (ainsi qu’un polissage général de ce que j’ai fait), car je pars en vacances le 3. De cette façon, si la revue est terminée, je pourrai la fusionner et la déployer à mon retour. Si vous avez d’autres commentaires, faites-le moi savoir avant, sinon je considérerai que tout va bien (ce qui semblait être le cas lors de nos tests hier ).
Je pense que les choses vont globalement bien. Mes notes du balayage manuel du fil d’e-mails de mon côté, que j’ai principalement balayé manuellement pour les en-têtes :
Topic for testing threading 2022-08-23
post msg-id detail
59/1 98 OP new topics for testing email threading
59/11 109 reply-to-topic in-reply-to 98 ref 98
59/2 100 reply-to-topic in-reply-to 98 ref 98
59/3 via-email uuid@discourse yes welcome in-reply-to 100 ref 98,100
not noted as a reply in the web ui
??? me-via-email ...kr@cskk glad to be here in-reply-to uuid@discourse no refs
not noted as a reply in the web ui
59/10 108 reply to earlier post in-reply-to ...kr@cskk ref 98,100,0aa@discourse,kr@cskk
59/5 103 thanks cameron in-reply-to kr@cskk refs 98,100,0aa@discourse,kr@cskk
???104 me-via-email ...zp@cskk in-reply-to 103 no refs
not noted as a reply in the web ui
59/7 105 no problem in-reply-to zp@cskk refs 98,100,00a@discourse,kr@cskk,103,zp@cskk
posted on web, reply to 104? aka zp@@cskk
not noted as a reply in the web UI (so, new-top-topic?)
quotes kr@cskk "glad to be here"
NEEDS REVIEW
59/9 107 expected or a bug in-reply-to 106 ref 98,100,0aa@discourse,kr@cskk,103,zp@cskk,105,106
quotes 59/8
Notes:
- email replies are not shown as replies in the web ui
- web multireplies only get one msg-id in the in-reply-to
- users do not get email copies of their own posts (email or web), would be nice to have an option in prefs for this
- web msg-ids seem to be forum post.id, would be nicer if topic.id/in-topic.id for easier tracing in headers
En résumé : Je n’ai trouvé aucun en-tête incorrect, mais j’ai noté certaines lacunes ci-dessus.
Je n’ai pas eu l’occasion de revoir votre code mis à jour, mais fonctionnellement, les choses semblent correctes.
Ou que vous ne voyez pas cette partie ? Pour cette dernière, nous n’affichons la réponse avec la flèche que si le message auquel vous répondez est plus haut dans le sujet, pas seulement le précédent :
Oh, je ne pensais pas que c’était nécessaire. Donc, si vous répondez à N messages via le web, tous les Message-IDs de ces messages devraient apparaître dans l’en-tête In-Reply-To, et ensuite References suit la logique actuelle d’un fil de discussion, de l’OP à un seul parent (dans notre cas, je choisis le message le plus récent comme seul parent) ?
Oui, c’est par conception pour ne pas vous envoyer des choses que vous avez déjà “vues”. Nous pourrions créer une autre tâche pour voir s’il y a une demande pour cela de la part de plus d’utilisateurs.
Le problème avec l’ID de sujet est qu’il est trop fragile et pas assez spécifique/unique. De plus, cela semblera un peu déroutant lorsqu’un message sera déplacé entre les sujets. Peut-être pouvons-nous inclure un en-tête personnalisé dans l’e-mail, par exemple X-Discourse-Topic-ID ou quelque chose de similaire (si cela est autorisé) pour permettre un suivi visuel plus facile ?
Ah. Alors que moi, en tant que personne non familière avec les forums par e-mail, je m’attendais à cet indicateur sur chaque réponse car je ne pense pas à cela comme une disposition de messagerie instantanée (peut-être). Donc mes attentes divergent de ce que vous avez choisi de faire.
Ce n’est pas nécessaire. Considérez cela comme un “contrôle de qualité”. Vous faites explicitement :
et vous pourriez simplement supprimer le [0] ici. Les clients pourraient alors utiliser un seul message-id ou faire quelque chose de très fantaisiste à leur guise et tout serait valide.
“Devraient” est un mot fort. Vous pourriez inclure tous les message-ids s’ils sont facilement accessibles. Vous n’êtes pas obligé, et le code est valide tel quel.
Ouais. Je sais que je l’aime personnellement pour savoir que mon message est bien arrivé sur la liste/le forum - l’e-mail étant très basé sur des files d’attente et certains gestionnaires de courrier d’ISP (tousse, grand opérateur australien, tousse) étant très… peu fiables, lents, etc. J’ai parfois vu d’autres personnes vouloir cela (dans les listes, mais c’est le mode dont nous parlons effectivement ici). La valeur par défaut pour une telle option devrait probablement être false.
En tant que nerd, j’aime avoir au moins un flux non filtré pour pouvoir prendre mes propres décisions politiques.
Étant donné que le Message-ID est effectivement opaque/défini une fois pour toutes, je ne considère pas cela comme un problème, sauf s’il y a une possibilité de réémettre le même message-id - si tous vos compteurs sont strictement monotones, je ne m’attendrais pas à ce que cela se produise. J’ai juste trouvé très fastidieux de faire correspondre post.id par exemple 98 à topic/post par exemple 59/1. Il aurait été utile d’avoir quelque chose comme category.id/topic.id/post-in-topic.id à la place de 98.
Ce serait également suffisant. Il s’agit simplement d’une commodité pour les en-têtes de débogage.
C’est toujours l’ancien code que vous regardez, il suffit de regarder add_experimental_identification_field_headers. Mais votre point tient toujours.
Il y a quelqu’un dans notre équipe d’infrastructure qui serait fermement d’accord avec cette déclaration, il partage un flux de travail et une perspective similaires aux vôtres
C’est juste, peut-être que je réintroduirai également l’ID du sujet, puisque outbound_message_id est en effet défini une fois et n’est pas modifié (en fonction de si le post est généré dans l’interface Web Discourse ou via un e-mail entrant).
Je n’en aurai probablement pas besoin maintenant puisque je rajoute l’ID du sujet dans le Message-ID une fois de plus.
En fait, je ne suis pas sûr de cela, j’ai le pressentiment que nous ne voulons pas vraiment l’ID du sujet dans ces Message-IDs, avoir juste l’ID du message le rend très simple. Je vais plutôt essayer ceci :
Cela me convient. J’ai juste trouvé particulièrement difficile de lier les en-têtes des messages électroniques aux publications car le post.id n’est pas évident dans l’interface utilisateur ou dans l’URL de la publication particulière sur le web. Le fait d’avoir cela présent dans un en-tête de contexte supplémentaire serait tout aussi bien.
Salut Cameron, j’étais à notre rencontre d’entreprise puis en vacances pendant les 2 dernières semaines, je reprends le rythme aujourd’hui. Si ce n’est pas fusionné cette semaine, ce sera certainement fusionné la semaine prochaine. Désolé pour les retards !
Par Martin Brennan via Discourse Meta le 20 sept. 2022 00:17 :
Salut Cameron, j’étais à la rencontre de notre entreprise puis en vacances pendant les 2 dernières semaines, je reprends le rythme aujourd’hui. Si ce n’est pas fusionné cette semaine, ce sera certainement fusionné la semaine prochaine. Mes excuses pour les retards !
Pas besoin de s’excuser. Je savais que tu étais absent, je n’étais pas sûr de ton timing ou de ton retour. Et je suppose qu’il est peut-être encore lundi là où tu es
Par Martin Brennan via Discourse Meta le 25 sept. 2022 à 23:29 :
Je viens de fusionner la Pull Request, j’essaierai de déployer le forum Python plus tard
aujourd’hui pour que vous puissiez commencer à l’utiliser sérieusement.
).
