Es gibt ein paar verschiedene Möglichkeiten, wie wir auf den/die übergeordneten Beitrag(e) verweisen, und die Zuordnung wird über die PostReply-Tabelle gespeichert, wobei reply_post_id den Beitrag darstellt, der die Antwort erstellt, und post_id auf das übergeordnete Element verweist. Eingehende E-Mails verwenden In-Reply-To, um diese zu verknüpfen, und aus der Discourse-Benutzeroberfläche heraus, wenn Sie mehrere Beiträge zitieren, werden mehrere PostReply-Datensätze erstellt, und wenn Sie die Schaltfläche “Antworten” auf einem einzelnen Beitrag verwenden, wird diese zum Erstellen eines PostReply-Datensatzes verwendet.
Ja, Entschuldigung, das hätte ich anmerken sollen, add_identification_field_headers wird nicht mehr verwendet, es ist alles in add_experimental_identification_field_headers, dem neuen Code. Vielen Dank für die Kommentare zum Code selbst, damit habe ich nicht gerechnet! Ich werde sie heute durchgehen.
@cameron-simpson Entschuldigen Sie, ich glaube, Sie haben einen früheren Commit in diesem PR überprüft. Ich habe den Code dafür jetzt neu aufgesetzt und erneut gepusht, um einen einzelnen Commit mit dem gesamten neuesten Code zu haben, den wir auf dieser Testseite getestet haben. Hoffentlich ist die Commit-Nachricht dort hilfreich und logisch.
Für References verwende ich, wenn der Benutzer auf einen Beitrag antwortet, die vollständige Kette der Message-IDs vom OP bis zum übergeordneten Beitrag in der Reihenfolge. Wenn zum Beispiel alle diese Beiträge eine direkte Kette von Antworten sind:
Beitrag 1 – discourse/post/500@test.site
Beitrag 2 – discourse/post/501@test.site
Beitrag 3 – discourse/post/502@test.site
Beitrag 4 – discourse/post/503@test.site
Beitrag 5 – discourse/post/504@test.site
Dann ist der In-Reply-To-Header für den letzten Beitrag:
Wenn ein neuer Beitrag erstellt wird, der nicht direkt auf den obigen Beitrag antwortet, z. B. Beitrag 6 – discourse/post/505@test.site, dann ist seine In-Reply-To-Message-ID <discourse/post/500@test.site> (der OP), und References ist <discourse/post/500@test.site>, was ebenfalls der OP ist.
Bitte lassen Sie mich wissen, wenn dies falsch ist, und ich kann es überarbeiten.
Von Martin Brennan über Discourse Meta am 23. Aug. 2022 23:59:
@cameron-simpson Entschuldigen Sie, ich glaube, Sie haben sich einen früheren
Commit in diesem PR angesehen. Ich habe den Code dafür neu aufgesetzt und erneut gepusht, um
einen einzelnen Commit mit dem gesamten neuesten Code zu haben, den wir auf dieser Testseite getestet haben.
Hoffentlich ist die Commit-Nachricht dort hilfreich und logisch.
Ich schaue noch einmal nach, danke.
Für References, wenn der Benutzer auf einen Beitrag antwortet, verwende ich die gesamte Kette von Message-IDs von der OP bis zum übergeordneten Beitrag in der Reihenfolge. Zum Beispiel, wenn alle diese Beiträge eine direkte Kette von Antworten sind:
Beitrag 1 – discourse/post/500@test.site
Beitrag 2 – discourse/post/501@test.site
Beitrag 3 – discourse/post/502@test.site
Beitrag 4 – discourse/post/503@test.site
Beitrag 5 – discourse/post/504@test.site
Klingt richtig.
Dann ist der In-Reply-To-Header für den letzten Beitrag:
In-Reply-To: <discourse/post/503@test.site>
Und References wird sein
Wenn ein neuer Beitrag erstellt wird, der nicht direkt auf den Beitrag darüber antwortet, z. B. Beitrag 6 – discourse/post/505@test.site, dann wird seine In-Reply-To-Message-ID <discourse/post/500@test.site> (die OP) sein, und References wird <discourse/post/500@test.site> sein, was ebenfalls die OP ist.
Danke. Ich habe auch vergessen zu erwähnen, dass wir tatsächlich zur Datenbank gehen müssen, um die References-Kette basierend auf den PostReply-Datensätzen neu zu erstellen. Sie werden das im neuesten Commit sehen.
@cameron-simpson Ich möchte nächste Woche mit diesem Code den internen Überprüfungsprozess starten (sowie die allgemeine Politur dessen, was ich getan habe), da ich am 3. in den Urlaub fahre. Auf diese Weise kann ich ihn zusammenführen und bereitstellen, sobald ich zurück bin, wenn die Überprüfung abgeschlossen ist. Wenn Sie weiteres Feedback haben, lassen Sie es mich bitte vorher wissen, ansonsten gehe ich davon aus, dass alles in Ordnung ist (was gestern bei unseren Tests der Fall zu sein schien ).
Ich denke, die Dinge sind größtenteils gut. Meine Notizen aus dem manuellen Durchgehen des E-Mail-Threads von meiner Seite, den ich größtenteils manuell nach Headern durchsucht habe:
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
Zusammenfassend: Ich habe keine fehlerhaften Header gefunden, aber einige der oben genannten Mängel festgestellt.
Ich hatte noch keine Gelegenheit, Ihren aktualisierten Code zu überprüfen, aber funktional scheint alles korrekt zu sein.
Oder dass Sie diesen Teil nicht sehen können? Letzteres, wir zeigen die Antwort mit dem Pfeil nur an, wenn der Beitrag, auf den Sie antworten, weiter oben im Thema steht und nicht nur der unmittelbar vorherige:
Oh, ich dachte nicht, dass dies erforderlich ist. Wenn Sie also über das Web auf N Beiträge antworten, sollten die Message-IDs all dieser Beiträge im In-Reply-To-Header angezeigt werden, und dann folgt References der aktuellen Logik eines Threads vom OP bis zu einem einzelnen Elternteil (in unserem Fall wähle ich den zuletzt erstellten Beitrag als einzelnes Elternteil)?
Ja, das ist absichtlich so, um Ihnen keine Dinge zu senden, die Sie bereits „gesehen“ haben. Wir könnten dies in einem separaten TODO auslagern, um zu sehen, ob dies von mehr Benutzern gewünscht wird.
Das Problem mit der Thema-ID ist, dass sie zu spröde und nicht spezifisch/eindeutig genug ist. Außerdem wird es etwas verwirrend erscheinen, wenn ein Beitrag zwischen Themen verschoben wird. Vielleicht können wir einen benutzerdefinierten Header in der E-Mail aufnehmen, z. B. X-Discourse-Topic-ID oder etwas Ähnliches (wenn das erlaubt ist), um eine einfachere visuelle Nachverfolgung zu ermöglichen?
Ah. Ich als E-Mail-Nicht-Forum-Nutzer habe erwartet, dass dieser Indikator bei jeder Antwort vorhanden ist, weil ich das nicht als Layout für Sofortnachrichten betrachte (vielleicht). Meine Erwartungen weichen also von dem ab, was Sie gewählt haben.
Es ist nicht erforderlich. Betrachten Sie es als “Servicequalität”. Sie gehen explizit:
und Sie könnten einfach [0] dort weglassen. Clients könnten dann nur eine Message-ID verwenden oder etwas sehr Verrücktes nach Belieben tun, und es wäre alles gültig.
“Sollten” ist ein starkes Wort. Sie könnten alle Message-IDs einbeziehen, wenn sie leicht zugänglich sind. Sie sind nicht verpflichtet, und der Code ist so, wie er ist, gültig.
Aye. Ich weiß, dass ich es selbst mag, damit ich weiß, dass mein Beitrag es auf die Liste/das Forum geschafft hat – E-Mails sind sehr warteschlangenbasiert und einige (hust, großer australischer Telekommunikationsanbieter, hust) ISP-Mailhandler sind sehr… unzuverlässig, langsam usw. usw. Gelegentlich habe ich gesehen, dass andere Leute das wollen (in Listen, aber das ist der Modus, über den wir hier effektiv sprechen). Die Standardeinstellung für eine solche Option sollte wahrscheinlich false sein.
Als Nerd mag ich es, zumindest einen ungefilterten Feed zu bekommen, damit ich meine eigenen politischen Entscheidungen treffen kann.
Da die Message-ID effektiv opak/einmalig gesetzt ist, sehe ich das nicht als Problem, es sei denn, es gibt Spielraum für die Neuausstellung derselben Message-ID – wenn alle Ihre Zähler streng monoton sind, erwarte ich nicht, dass das passiert. Ich fand es nur sehr mühsam, post.id z. B. 98 mit topic/post z. B. 59/1 abzugleichen. Es wäre praktisch gewesen, stattdessen so etwas wie category.id/topic.id/post-in-topic.id anstelle der 98 zu haben.
Das wäre auch ausreichend. Das ist nur Bequemlichkeit auf der Seite der Debugging-Header.
Das ist immer noch der alte Code, den Sie sich dort ansehen. Sie müssen nur add_experimental_identification_field_headers betrachten. Aber Ihr Punkt bleibt bestehen.
Es gibt jemanden in unserem Infrastrukturteam, der dieser Aussage entschieden zustimmen würde, er teilt einen ähnlichen Arbeitsablauf und eine ähnliche Denkweise wie Sie
Das ist in Ordnung, vielleicht führe ich die Themen-ID wieder ein, da die outbound_message_id tatsächlich einmal gesetzt und nicht geändert wird (basierend darauf, ob der Beitrag über die Discourse-Weboberfläche oder per eingehender E-Mail generiert wird).
Das wird wahrscheinlich nicht mehr benötigt, da ich die Themen-ID wieder in die Message-ID aufnehme.
Ich bin mir da eigentlich nicht sicher, ich habe das Bauchgefühl, dass wir die Topic-ID in diesen Message-IDs nicht wirklich wollen, die reine Post-ID macht es super einfach. Ich werde stattdessen Folgendes versuchen:
Das ist in Ordnung für mich. Ich fand es nur besonders schwierig, E-Mail-Nachrichten-Header mit Beiträgen zu verknüpfen, da die post.id in der Benutzeroberfläche oder der URL des jeweiligen Beitrags im Web nicht ersichtlich ist. Wenn diese in einem zusätzlichen Kontext-Header vorhanden wäre, wäre das genauso gut.
Hallo Cameron, ich war auf unserem Firmen-Meetup und dann zwei Wochen im Urlaub und komme heute erst wieder richtig in Schwung. Wenn es diese Woche nicht gemerged wird, dann wird es definitiv nächste Woche gemerged. Entschuldigung für die Verzögerungen!
Von Martin Brennan via Discourse Meta am 20. Sep. 2022 00:17 Uhr:
Hallo Cameron, ich war auf unserem Firmen-Treffen und dann 2 Wochen im Urlaub, komme heute erst wieder in Schwung. Wenn es diese Woche nicht gemerged wird, dann wird es definitiv nächste Woche gemerged. Entschuldigung für die Verzögerungen!
Keine Entschuldigung nötig. Ich wusste, dass du weg warst, war mir aber nicht sicher wegen deines Timings oder deiner Rückkehr. Und ich schätze, bei dir ist es vielleicht noch Montag
).
