Hay varias formas de enlazar a la(s) publicación(es) principal(es), y la asociación se almacena a través de la tabla PostReply, con reply_post_id representando la publicación que está haciendo la respuesta y post_id haciendo referencia a la principal. Los correos electrónicos entrantes usan In-Reply-To para vincularlos, y desde la interfaz de usuario de Discourse, si citas varias publicaciones, se crean varios registros de PostReply, y si usas el botón “Responder” en una sola publicación, se utiliza para crear un registro de PostReply.
Sí, lo siento, debería haberlo notado, add_identification_field_headers ya no se usará, todo está en add_experimental_identification_field_headers, el nuevo código. ¡Gracias por hacer comentarios sobre el código en sí, no lo esperaba! Los revisaré hoy.
@cameron-simpson, mis disculpas, creo que revisaste una versión anterior de ese PR. He vuelto a basar el código y lo he vuelto a enviar para tener un solo commit con todo el código más reciente que hemos estado probando en ese sitio de prueba. Espero que el mensaje del commit sea útil y lógico.
Para References, si el usuario está respondiendo a una publicación, uso la cadena completa de Message-IDs desde el OP hasta la publicación principal en orden. Por ejemplo, si todas estas publicaciones son una cadena directa de respuestas:
Publicación 1 – discourse/post/500@test.site
Publicación 2 – discourse/post/501@test.site
Publicación 3 – discourse/post/502@test.site
Publicación 4 – discourse/post/503@test.site
Publicación 5 – discourse/post/504@test.site
Entonces, el encabezado In-Reply-To para la última publicación será:
Si se crea una nueva publicación que no responde directamente a la publicación anterior, por ejemplo, Publicación 6 – discourse/post/505@test.site, entonces su Message-ID In-Reply-To será <discourse/post/500@test.site> (el OP), y References será <discourse/post/500@test.site> que también es el OP.
Por favor, hazme saber si esto es incorrecto y puedo revisarlo.
Por Martin Brennan vía Discourse Meta el 23 de agosto de 2022 23:59:
@cameron-simpson mis disculpas, creo que puede que hayas revisado un commit anterior en ese PR. He vuelto a basar el código y he vuelto a enviarlo para tener un solo commit con todo el código más reciente que hemos estado probando en ese sitio de prueba. Espero que el mensaje del commit sea útil y lógico.
Lo miraré de nuevo, gracias.
Para References, si el usuario responde a una publicación, uso la cadena completa de Message-IDs desde el OP hasta la publicación principal en orden. Por ejemplo, si todas estas publicaciones son una cadena directa de respuestas:
Publicación 1 – discourse/post/500@test.site
Publicación 2 – discourse/post/501@test.site
Publicación 3 – discourse/post/502@test.site
Publicación 4 – discourse/post/503@test.site
Publicación 5 – discourse/post/504@test.site
Suena correcto.
Entonces, la cabecera In-Reply-To para la última publicación será:
In-Reply-To: <discourse/post/503@test.site>
Y References será
Si se crea una nueva publicación que no responde directamente a la publicación anterior, por ejemplo, Publicación 6 – discourse/post/505@test.site, entonces su Message-ID In-Reply-To será <discourse/post/500@test.site> (el OP), y References será <discourse/post/500@test.site> que también es el OP.
Gracias. También olvidé mencionar que efectivamente tenemos que ir a la base de datos para recrear la cadena References basándonos en los registros de PostReply, lo verás en el último commit.
@cameron-simpson Me gustaría iniciar el proceso de revisión interna con este código la próxima semana (así como un pulido general de lo que he hecho), ya que me voy de vacaciones el día 3. De esa manera, si la revisión se completa, podré fusionarlo y desplegarlo una vez que regrese. Si tiene algún comentario adicional, por favor hágame saber antes de entonces, de lo contrario asumiré que todo está bien (lo cual pareció ser el caso durante nuestras pruebas ayer ).
Creo que las cosas están mayormente bien. Mis notas de la revisión manual del hilo de correo electrónico por mi parte, que he revisado en su mayoría para ver las cabeceras:
Tema para probar el encadenamiento 2022-08-23
publicación id-mensaje detalle
59/1 98 OP nuevos temas para probar el encadenamiento de correos electrónicos
59/11 109 responder-a-tema en-respuesta-a 98 ref 98
59/2 100 responder-a-tema en-respuesta-a 98 ref 98
59/3 vía-email uuid@discourse sí bienvenido en-respuesta-a 100 ref 98,100
no se señala como respuesta en la interfaz web
??? yo-vía-email ...kr@cskk encantado de estar aquí en-respuesta-a uuid@discourse sin referencias
no se señala como respuesta en la interfaz web
59/10 108 responder a publicación anterior en-respuesta-a ...kr@cskk ref 98,100,0aa@discourse,kr@cskk
59/5 103 gracias cameron en-respuesta-a kr@cskk refs 98,100,0aa@discourse,kr@cskk
???104 yo-vía-email ...zp@cskk en-respuesta-a 103 sin referencias
no se señala como respuesta en la interfaz web
59/7 105 no hay problema en-respuesta-a zp@cskk refs 98,100,00a@discourse,kr@cskk,103,zp@cskk
publicado en la web, ¿respuesta a 104? alias zp@@cskk
no se señala como respuesta en la interfaz web (entonces, ¿nuevo tema principal?)
cita a kr@cskk "encantado de estar aquí"
REQUIERE REVISIÓN
59/9 107 esperado o un error en-respuesta-a 106 ref 98,100,0aa@discourse,kr@cskk,103,zp@cskk,105,106
cita 59/8
Notas:
- las respuestas por correo electrónico no se muestran como respuestas en la interfaz web
- las respuestas múltiples de la web solo obtienen un id-mensaje en el campo en-respuesta-a
- los usuarios no reciben copias por correo electrónico de sus propias publicaciones (por correo electrónico o web), sería bueno tener una opción en las preferencias para esto
- los id-mensajes de la web parecen ser forum post.id, sería mejor si fueran topic.id/in-topic.id para facilitar el seguimiento en las cabeceras
En resumen: No encontré ninguna cabecera incorrecta, pero señalo algunas deficiencias arriba.
Aún no he tenido la oportunidad de revisar tu código actualizado, pero funcionalmente las cosas parecen correctas.
¿O que no puedes ver esta parte? Para esto último, solo mostramos la respuesta con la flecha si la publicación a la que respondes está más arriba en el tema, no solo una anterior:
Oh, no pensé que esto fuera necesario, así que si respondes a N publicaciones a través de la web, ¿todos los Message-IDs de esas publicaciones deberían aparecer en el encabezado In-Reply-To, y luego References sigue la lógica actual de un hilo desde el OP hasta un solo padre (en nuestro caso, elijo la publicación creada más recientemente como el único padre)?
Sí, esto es por diseño para no enviarte cosas que ya has “visto”, podríamos plantear eso en otro TODO para ver si hay demanda para esto de más usuarios.
El problema con el ID del tema es que es demasiado frágil y no es lo suficientemente específico/único, además parecerá un poco confuso cuando una publicación se mueva entre temas. ¿Quizás podamos incluir un encabezado personalizado en el correo electrónico, por ejemplo, X-Discourse-Topic-ID o algo así (si está permitido) para permitir un seguimiento visual más fácil?
Ah. Mientras que yo, como persona no forera de correo electrónico, esperaba ese indicador en cada respuesta porque no lo estoy pensando como un diseño de mensajería instantánea (quizás). Así que mis expectativas difieren de lo que has elegido hacer.
No es necesario. Piénsalo como “calidad de servicio”. Tú explícitamente haces:
y podrías simplemente omitir el [0] ahí. Los clientes podrían usar un solo message-id o hacer algo muy peculiar a su antojo y todo sería válido.
“Deberían” es una palabra fuerte. Podrías incluir todos los message-ids si los tienes a mano. No estás obligado, y el código es válido tal como está.
Sí. Sé que a mí mismo me gusta para saber que mi publicación llegó a la lista/foro; el correo electrónico se basa mucho en colas y algunos manejadores de correo de ISP (tos, gran empresa de telecomunicaciones australiana, tos) son muy… poco fiables, lentos, etc., etc. Ocasionalmente he visto que otras personas quieren esto (en listas, pero ese es el modo del que estamos hablando efectivamente aquí). El valor predeterminado para tal opción probablemente debería ser falso.
Como nerd, me gusta poder obtener al menos un feed sin filtrar para poder tomar mis propias decisiones políticas.
Dado que el Message-ID es efectivamente opaco/establecido una vez, no lo veo como un problema a menos que haya margen para reemitir el mismo message-id; si todos tus contadores son estrictamente monotónicos, no esperaría que eso sucediera. Simplemente me pareció muy tedioso hacer coincidir post.id, por ejemplo, 98, con el tema/publicación, por ejemplo, 59/1. Hubiera sido útil tener algo como category.id/topic.id/post-in-topic.id allí en lugar del 98.
Eso también sería suficiente. Esto es solo una conveniencia en el lado de las cabeceras de depuración.
Ese sigue siendo el código antiguo que estás mirando, solo necesitas mirar add_experimental_identification_field_headers. Pero tu punto sigue siendo válido.
Hay alguien en nuestro equipo de infraestructura que estaría de acuerdo firmemente con esta declaración, comparte un flujo de trabajo y una perspectiva similar a la tuya
Eso está bien, tal vez reintroduzca el ID del tema también, ya que outbound_message_id se establece una vez y no se cambia (según si la publicación se genera en la interfaz web de Discourse o a través de un correo electrónico entrante).
Probablemente no necesitaré esto ahora, ya que estoy agregando el ID del tema al Message-ID una vez más.
En realidad, no estoy seguro de esto, tengo la corazonada de que realmente no queremos el ID del tema en esos Message-IDs, tener solo el ID de la publicación lo hace muy simple. Intentaré esto en su lugar:
Está bien para mí. Simplemente me resultó particularmente difícil vincular los encabezados de los mensajes de correo electrónico a las publicaciones porque el post.id no es evidente en la interfaz de usuario ni en la URL de la publicación en particular en la web. Tener eso presente en un encabezado de contexto adicional sería igual de bueno.
Hola Cameron, estuve en la reunión de nuestra empresa y luego de vacaciones durante las últimas 2 semanas, volviendo a la normalidad hoy. Si no se fusiona esta semana, definitivamente se fusionará la próxima semana. ¡Disculpas por las demoras!
Por Martin Brennan vía Discourse Meta el 20 de septiembre de 2022 00:17:
Hola Cameron, estuve en la reunión de nuestra empresa y luego de vacaciones durante las últimas 2 semanas, volviendo a la normalidad hoy. Si no se fusiona esta semana, definitivamente se fusionará la próxima semana. ¡Disculpas por las demoras!
No hay necesidad de disculpas. Sabía que habías estado fuera, no estaba seguro de tu horario o regreso. Y supongo que todavía podría ser lunes donde estás
).
