Ci sono diversi modi per collegarci al post (o ai post) padre e l’associazione viene memorizzata tramite la tabella PostReply, con reply_post_id che rappresenta il post che sta effettuando la risposta e post_id che fa riferimento al padre. Le email in arrivo utilizzano In-Reply-To per collegarli, e dall’interfaccia utente di Discourse, se citi più post, vengono creati più record PostReply, e se usi il pulsante “Rispondi” su un singolo post, questo viene utilizzato per creare un record PostReply.
Sì, mi dispiace, avrei dovuto notarlo, add_identification_field_headers non verrà più utilizzato, è tutto in add_experimental_identification_field_headers, il nuovo codice. Grazie per aver commentato il codice stesso, non me lo aspettavo! Ci lavorerò oggi.
@cameron-simpson mi scuso, penso che tu possa aver esaminato un commit precedente in quella PR. Ho ora ribasato il codice per essa e ho fatto nuovamente push per avere un singolo commit con tutto il codice più recente che abbiamo testato su quel sito di prova. Spero che il messaggio del commit sia utile e logico.
Per References, se l’utente sta rispondendo a un post, uso l’intera catena di Message-ID dall’OP fino al post genitore in ordine. Ad esempio, se tutti questi post sono una catena diretta di risposte:
Post 1 – discourse/post/500@test.site
Post 2 – discourse/post/501@test.site
Post 3 – discourse/post/502@test.site
Post 4 – discourse/post/503@test.site
Post 5 – discourse/post/504@test.site
Allora l’header In-Reply-To per l’ultimo post sarà:
Se viene creato un nuovo post che non risponde direttamente al post sopra, ad esempio Post 6 – discourse/post/505@test.site, allora il suo Message-ID In-Reply-To sarà <discourse/post/500@test.site> (l’OP), e References sarà <discourse/post/500@test.site> che è anche l’OP.
Per favore, fammi sapere se questo è errato e posso rivederlo.
Di Martin Brennan tramite Discourse Meta alle 23:59 del 23 agosto 2022:
@cameron-simpson mi scuso, penso che tu possa aver rivisto un commit precedente in quella PR. Ho nuovamente riorganizzato il codice per essa e ho eseguito nuovamente il push per avere un singolo commit con tutto il codice più recente che abbiamo testato su quel sito di test. Spero che il messaggio del commit sia utile e logico.
Darò un’altra occhiata, grazie.
Per References, se l’utente risponde a un post, utilizzo l’intera catena di Message-ID dall’OP fino al post genitore in ordine. Ad esempio, se tutti questi post sono una catena diretta di risposte:
Post 1 – discourse/post/500@test.site
Post 2 – discourse/post/501@test.site
Post 3 – discourse/post/502@test.site
Post 4 – discourse/post/503@test.site
Post 5 – discourse/post/504@test.site
Sembra corretto.
Allora l’header In-Reply-To per l’ultimo post sarà:
In-Reply-To: <discourse/post/503@test.site>
E References sarà
Se viene creato un nuovo post che NON risponde direttamente al post sopra, ad esempio Post 6 – discourse/post/505@test.site, allora il suo Message-ID In-Reply-To sarà <discourse/post/500@test.site> (l’OP), e References sarà <discourse/post/500@test.site> che è anche l’OP.
Grazie. Ho anche dimenticato di menzionare che dobbiamo effettivamente andare al database per ricreare la catena References basata sui record PostReply, lo vedrai nell’ultimo commit.
@cameron-simpson Vorrei avviare il processo di revisione interna di questo codice la prossima settimana (oltre a una revisione generale di ciò che ho fatto), dato che sarò in ferie il 3. In questo modo, se la revisione sarà completata, potrò unirla e distribuirla al mio ritorno. Se hai ulteriori feedback, fammelo sapere prima di allora, altrimenti assumerò che vada tutto bene (cosa che sembrava essere durante i nostri test ieri ).
Penso che le cose siano per lo più buone. Le mie note dalla scansione manuale del thread di email dalla mia parte, che ho per lo più scansionato manualmente per gli header:
Argomento per il test del threading 2022-08-23
post msg-id detail
59/1 98 OP nuovi argomenti per il test del threading delle email
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 sì benvenuto in-reply-to 100 ref 98,100
non notato come risposta nell'interfaccia web
??? me-via-email ...kr@cskk lieto di essere qui in-reply-to uuid@discourse nessun ref
non notato come risposta nell'interfaccia web
59/10 108 risposta al post precedente in-reply-to ...kr@cskk ref 98,100,0aa@discourse,kr@cskk
59/5 103 grazie cameron in-reply-to kr@cskk refs 98,100,0aa@discourse,kr@cskk
???104 me-via-email ...zp@cskk in-reply-to 103 nessun ref
non notato come risposta nell'interfaccia web
59/7 105 nessun problema in-reply-to zp@cskk refs 98,100,00a@discourse,kr@cskk,103,zp@cskk
postato sul web, risposta a 104? aka zp@@cskk
non notato come risposta nell'interfaccia web (quindi, nuovo argomento principale?)
cita kr@cskk "lieto di essere qui"
DA RIVEDERE
59/9 107 previsto o un bug in-reply-to 106 ref 98,100,0aa@discourse,kr@cskk,103,zp@cskk,105,106
cita 59/8
Note:
- le risposte via email non vengono mostrate come risposte nell'interfaccia web
- le risposte multiple sul web ottengono solo un msg-id nell'in-reply-to
- gli utenti non ricevono copie via email dei propri post (via email o web), sarebbe bello avere un'opzione nelle preferenze per questo
- gli id dei messaggi web sembrano essere forum post.id, sarebbe meglio se topic.id/in-topic.id per una più facile tracciabilità negli header
In sintesi: non ho trovato header errati, ma noto alcune carenze sopra.
Non ho avuto modo di rivedere il tuo codice aggiornato, ma funzionalmente le cose sembrano corrette.
O che non riesci a vedere questa parte? Per quest’ultima, mostriamo la freccia Rispondi solo se il post a cui stai rispondendo si trova più in alto nel thread, non solo quello precedente:
Oh, non pensavo fosse necessario, quindi se rispondi a N post tramite web, tutti gli ID messaggio di quei post dovrebbero apparire nell’intestazione In-Reply-To, e poi References segue la logica corrente di un thread dall’OP fino a un singolo genitore (nel nostro caso scelgo il post creato più di recente come singolo genitore)?
Sì, questo è intenzionale per non inviarti cose che hai già “visto”, potremmo creare un TODO separato per vedere se c’è una richiesta per questo da parte di più utenti.
Il problema con l’ID del topic è che è troppo fragile e non abbastanza specifico/unico, inoltre sembrerà un po’ confuso quando un post viene spostato tra topic. Forse possiamo includere un’intestazione personalizzata nell’email, ad esempio X-Discourse-Topic-ID o qualcosa di simile (se consentito) per consentire un tracciamento visivo più semplice?
Ah. Mentre io, come persona non avvezza ai forum via email, mi aspettavo quell’indicatore su ogni risposta perché non la sto pensando come un layout di messaggistica istantanea (forse). Quindi le mie aspettative sono in contrasto con ciò che avete scelto di fare.
Non è necessario. Pensala come una “qualità del servizio”. Fai esplicitamente:
e potresti semplicemente rimuovere [0] lì. I client potrebbero quindi utilizzare un solo message-id o fare qualcosa di molto strano a loro piacimento e sarebbe tutto valido.
“Dovrebbero” è una parola forte. Potresti includere tutti i message-id se sono facilmente a portata di mano. Non sei obbligato e il codice è valido così com’è.
Sì. So che a me piace per sapere che il mio post è arrivato alla lista/forum - l’email è molto basata su code e alcuni (tosse, grande operatore telefonico australiano, tosse) gestori di posta ISP sono molto… inaffidabili, lenti, ecc. ecc. Occasionalmente ho visto altre persone desiderare questo (nelle liste, ma questa è la modalità di cui stiamo effettivamente parlando qui). L’impostazione predefinita per tale opzione dovrebbe probabilmente essere falsa.
Come nerd, mi piace avere almeno un feed non filtrato in modo da poter prendere le mie decisioni politiche.
Dato che il Message-ID è effettivamente opaco/impostato una volta sola, non lo vedo come un problema a meno che non ci sia la possibilità di riemettere lo stesso message-id - se tutti i tuoi contatori sono strettamente monotoni non mi aspetto che accada. Ho semplicemente trovato molto noioso abbinare post.id ad esempio 98 a topic/post ad esempio 59/1. Sarebbe stato utile avere qualcosa come category.id/topic.id/post-in-topic.id lì invece di 98.
Anche questo sarebbe sufficiente. Si tratta solo di comodità per gli header di debug.
Quello è ancora il vecchio codice che stai guardando, devi solo guardare add_experimental_identification_field_headers. Ma il tuo punto rimane valido.
C’è qualcuno nel nostro team di infrastruttura che sarebbe pienamente d’accordo con questa affermazione, condivide un flusso di lavoro e una prospettiva simili alla tua
Va bene, forse reintrodurrò anche l’ID dell’argomento, dato che outbound_message_id viene effettivamente impostato una volta e non viene modificato (in base al fatto che il post sia generato nell’interfaccia web di Discourse o tramite un’e-mail in arrivo).
Probabilmente non ne avrò più bisogno ora che sto aggiungendo nuovamente l’ID dell’argomento al Message-ID.
In realtà non sono sicuro di questo, ho la sensazione che non vogliamo davvero l’ID dell’argomento in questi Message-ID, avere solo l’ID del post lo rende super semplice. Proverò invece questo:
Per me va bene. Ho trovato particolarmente difficile collegare le intestazioni dei messaggi e-mail ai post perché l’id.post non è evidente nell’interfaccia utente o nell’URL del post specifico sul web. Averlo presente in un’intestazione di contesto aggiuntiva sarebbe altrettanto valido.
Ciao Cameron, sono stato al nostro incontro aziendale e poi in vacanza per le ultime 2 settimane, sto riprendendo il ritmo solo oggi. Se non verrà unito questa settimana, sarà sicuramente unito la prossima settimana. Mi scuso per i ritardi!
Di Martin Brennan tramite Discourse Meta alle 20:09:2022 00:17:
Ciao Cameron, sono stato al meetup della nostra azienda e poi in vacanza per le ultime 2 settimane, sto riprendendo le attività oggi. Se non viene unito questa settimana, sarà sicuramente unito la prossima settimana. Mi scuso per i ritardi!
Non c’è bisogno di scuse. Sapevo che eri via, non ero sicuro dei tuoi tempi o del tuo ritorno. E immagino che dove ti trovi sia ancora lunedì
).
