부모 포스트(들)에 연결하는 몇 가지 다른 방식이 있으며, 이 연관관계는 PostReply 테이블을 통해 저장됩니다. 여기서 reply_post_id는 답변을 하는 포스트를 나타내고, post_id는 부모 포스트를 참조합니다. 수신된 이메일은 In-Reply-To 헤더를 사용하여 이러한 연결을 수행하며, Discourse UI에서 여러 포스트를 인용하면 여러 개의 PostReply 레코드가 생성됩니다. 단일 포스트의 “답변” 버튼을 사용하면 해당 포스트에 대한 PostReply 레코드가 생성됩니다.
네, 죄송합니다. 그 점을 언급했어야 했는데, add_identification_field_headers는 더 이상 사용되지 않으며, 새로운 코드는 모두 add_experimental_identification_field_headers에 있습니다. 코드 자체에 주석을 달아주셔서 감사합니다. 예상하지 못했습니다! 오늘 그 내용을 확인해 보겠습니다.
@cameron-simpson 죄송합니다. 해당 PR에서 이전 커밋을 검토하셨을 것 같습니다. 이제 코드를 리베이스하여 다시 푸시했습니다. 테스트 사이트에서 테스트해 온 최신 코드가 모두 포함된 단일 커밋으로 변경했습니다. 해당 커밋 메시지가 도움이 되고 논리적일 것으로 기대합니다.
References의 경우, 사용자가 게시물에 답글을 작성하면 OP(원본 게시물)부터 부모 게시물까지의 Message-ID 전체 체인을 순서대로 사용합니다. 예를 들어, 다음 게시물들이 모두 직접적인 답글 체인이라면:
discourse/post/500@test.sitediscourse/post/501@test.sitediscourse/post/502@test.sitediscourse/post/503@test.sitediscourse/post/504@test.site그러면 마지막 게시물의 In-Reply-To 헤더는 다음과 같습니다:
In-Reply-To: <discourse/post/503@test.site>그리고 References는 다음과 같습니다:
References: <discourse/post/500@test.site> <discourse/post/501@test.site> <discourse/post/502@test.site> <discourse/post/503@test.site>위 게시물에 직접 답글이 아닌 새로운 게시물이 생성되는 경우, 예를 들어 Post 6 – discourse/post/505@test.site라면, 그 In-Reply-To Message-ID는 <discourse/post/500@test.site>(OP)가 되고, References도 OP인 <discourse/post/500@test.site>가 됩니다.
이 내용이 잘못되었다면 알려 주세요. 수정하겠습니다.
Martin Brennan, Discourse Meta, 2022년 8월 23일 23:59:
@cameron-simpson 죄송합니다. 해당 PR에서 이전 커밋을 검토하신 것 같습니다. 이제 코드를 리베이스하여 다시 푸시했습니다. 이제 테스트 사이트에서 테스트해 온 최신 코드가 모두 포함된 단일 커밋으로 되어 있습니다. 해당 커밋 메시지가 유용하고 논리적이라는 것을 바랍니다.
한 번 더 확인해 보겠습니다. 감사합니다.
References의 경우, 사용자가 게시물에 답글을 작성하면 OP(최초 게시물)부터 부모 게시물까지의 Message-ID 전체 체인을 순서대로 사용합니다. 예를 들어, 이 모든 게시물이 직접적인 답글 체인이라면:
- 게시물 1 –
discourse/post/500@test.site- 게시물 2 –
discourse/post/501@test.site- 게시물 3 –
discourse/post/502@test.site- 게시물 4 –
discourse/post/503@test.site- 게시물 5 –
discourse/post/504@test.site
올바르게 보입니다.
그렇다면 마지막 게시물의
In-Reply-To헤더는 다음과 같습니다:
In-Reply-To: <discourse/post/503@test.site>
그리고References는 다음과 같습니다.References: <discourse/post/500@test.site> <discourse/post/501@test.site> <discourse/post/502@test.site> <discourse/post/503@test.site>
이것도 올바릅니다.
위 게시물에 직접 답글을 작성하지 않고 새 게시물이 생성되는 경우, 예를 들어 게시물 6 –
discourse/post/505@test.site라면, 그In-Reply-ToMessage-ID는<discourse/post/500@test.site>(OP)가 되고,References도 OP인<discourse/post/500@test.site>가 됩니다.
이것도 모두 올바릅니다.
감사합니다,
Cameron Simpson cs@cskk.id.au
감사합니다. 또한 PostReply 레코드에 기반하여 References 체인을 다시 생성하려면 데이터베이스로 이동해야 한다는 점도 언급을 잊고 있었습니다. 최신 커밋에서 이를 확인하실 수 있습니다.
@cameron-simpson 다음 주에 이 코드에 대한 내부 검토 프로세스를 시작하고 싶습니다(지금까지 작성한 부분의 전반적인 마무리 작업도 포함해서요). 3일에 휴가를 가거든요. 그렇게 하면 검토가 완료되면 복귀 후 바로 병합하고 배포할 수 있습니다. 추가 피드백이 있으시면 그때까지 알려주세요. 그렇지 않으면 모든 것이 문제없다고 가정하겠습니다(어제 테스트 중에 그렇게 보였으니까요 
).
전반적으로 괜찮은 것 같습니다. 제가 이메일 스레드를 대충 훑어본 노트를 첨부합니다. 대부분 헤더 중심으로 확인했습니다:
테스트용 스레딩 주제 2022-08-23
게시물 msg-id 상세
59/1 98 OP 새로운 이메일 스레딩 테스트 주제
59/11 109 주제에 대한 답장 in-reply-to 98 ref 98
59/2 100 주제에 대한 답장 in-reply-to 98 ref 98
59/3 via-email uuid@discourse 네, 환영합니다 in-reply-to 100 ref 98,100
웹 UI에서 답장으로 표시되지 않음
??? me-via-email ...kr@cskk 여기 있어 기쁩니다 in-reply-to uuid@discourse ref 없음
웹 UI에서 답장으로 표시되지 않음
59/10 108 이전 게시물에 대한 답장 in-reply-to ...kr@cskk ref 98,100,0aa@discourse,kr@cskk
59/5 103 감사합니다, 캐머런 in-reply-to kr@cskk refs 98,100,0aa@discourse,kr@cskk
???104 me-via-email ...zp@cskk in-reply-to 103 ref 없음
웹 UI에서 답장으로 표시되지 않음
59/7 105 문제없습니다 in-reply-to zp@cskk refs 98,100,00a@discourse,kr@cskk,103,zp@cskk
웹에서 게시됨, 104에 대한 답장? aka zp@@cskk
웹 UI에서 답장으로 표시되지 않음 (즉, 새 주제?)
kr@cskk의 "여기 있어 기쁩니다" 인용
검토 필요
59/9 107 예상된 동작이거나 버그 in-reply-to 106 ref 98,100,0aa@discourse,kr@cskk,103,zp@cskk,105,106
59/8 인용
노트:
- 이메일 답장은 웹 UI에서 답장으로 표시되지 않음
- 웹 다중 답장은 in-reply-to에 하나의 msg-id만 포함
- 사용자는 자신의 게시물(이메일 또는 웹)에 대한 이메일 사본을 받지 않음, 설정에 이 옵션이 있으면 좋겠음
- 웹 msg-id는 포럼 post.id인 것 같음, 헤더에서 추적이 더 쉽도록 topic.id/in-topic.id가 더 나을 것
요약하자면: 잘못된 헤더는 발견하지 못했지만, 위에서 언급한 몇 가지 단점이 있습니다.
업데이트된 코드를 검토할 여유가 없었지만, 기능적으로는 정상이 것으로 보입니다.
감사합니다,
캐머런
Cameron, 감사합니다!
이 부분에 대해 좀 더 자세히 설명해 주시겠어요? 말씀하시는 것이 이것이 안 보이는 건가요?
아니면 이 부분이 안 보이는 건가요? 후자의 경우, 답글을 작성 중인 게시물이 주제 내에서 더 위에 위치해 있을 때만 화살표가 포함된 '답글’을 표시합니다. 바로 직전 게시물 하나인 경우에는 표시하지 않습니다:
이것이 필수라고 생각하지 못했습니다. 웹을 통해 N개의 게시물에 답글을 보낼 경우, 해당 모든 게시물의 Message-ID가 In-Reply-To 헤더에 표시되어야 하며, References는 현재 논스레드 로직을 따릅니다. 즉, OP(최초 게시물)에서 단일 부모 게시물까지 이어지는 구조입니다(우리의 경우 가장 최근에 생성된 게시물을 단일 부모로 선택했습니다)?
네, 이는 사용자가 이미 "확인"한 내용을 다시 보내지 않기 위한 의도된 동작입니다. 더 많은 사용자들이 이 기능을 원할지 확인하기 위해 별도의 TODO 항목으로 분리해 볼 수 있습니다.
topic ID의 문제는 너무 취약하고 특정/고유성이 부족하다는 점이며, 게시물이 주제 사이로 이동할 때 다소 혼란스러워 보일 수 있습니다. 이메일에 X-Discourse-Topic-ID 또는 유사한 사용자 정의 헤더를 포함하여(허용된다면) 시각적 추적을 쉽게 할 수 있을까요?
아니요, 그 아이콘은 보입니다.
아. 저는 이메일을 사용하는 비(非)포럼 사용자로서, 인스턴트 메신저 레이아웃(아마도)으로 이 상황을 생각하지 않기 때문에 모든 답변에 해당 표시기가 표시될 것으로 기대했습니다. 그래서 제 기대치가 여러분이 선택한 방식과 다릅니다.
필수는 아닙니다. 이를 '서비스 품질(QoS)'로 생각하시면 됩니다. 여러분은 명시적으로 이렇게 가고 있습니다:
@message.header['In-Reply-To'] = referenced_post_message_ids[0] || topic_canonical_reference_id
여기서 [0]만 제거하면 됩니다. 그러면 클라이언트는 하나의 message-id만 사용하거나, 원하는 대로 매우 기발한 일을 할 수 있으며, 모두 유효할 것입니다.
'Should(해야 한다)'는 강한 표현입니다. 쉽게 구할 수 있다면 모든 message-id를 포함할 수 있습니다. 의무는 아니며, 현재 코드는 유효합니다.
네. 저도 제 게시물이 목록/포럼에 잘 도달했는지 알 수 있어서 이 기능이 좋습니다. 이메일은 매우 큐 기반이며, 일부(하아, 대형 호주 통신사, 하아) ISP 메일 처리기가 매우… 불안정하고 느리거나 하는 등의 문제가 있기 때문입니다. 가끔 다른 사람들이 이 기능을 원하는 것을 본 적도 있습니다(목록에서, 하지만 여기서는 사실상 그 모드를 이야기하고 있는 것이죠). 이러한 옵션의 기본값은 false여야 할 것입니다.
너드(기술 마니아)로서, 나는 최소한 필터링되지 않은 피드를 받아서 나만의 정책 결정을 내릴 수 있는 것을 좋아합니다.
Message-ID가 사실상 불투명하고 한 번만 설정된다는 점을 고려할 때, 같은 message-id를 _재발급_할 여지가 없는 한 이를 문제로 보지 않습니다. 모든 카운터가 엄격히 단조 증가한다면 그런 일이 일어나지 않을 것으로 예상합니다. 저는 post.id(예: 98)를 토픽/게시물(예: 59/1)과 매칭하는 것이 매우 번거롭게 느껴졌습니다. 98 대신 category.id/topic.id/post-in-topic.id와 같은 것이 있으면 편리했을 것입니다.
그것도 충분할 것입니다. 이것은 단순히 디버깅 헤더 측면에서의 편의성 문제입니다.
감사합니다,
Cameron
여기서 보고 계신 것은 여전히 구버전 코드입니다. add_experimental_identification_field_headers만 확인하시면 됩니다. 하지만 말씀하신 지적은 여전히 타당합니다.
우리 인프라 팀에는 이 발언에 강력히 동의할 누군가가 있습니다. 당신과 유사한 워크플로우와 관점을 가지고 있으니까요 
공감합니다. outbound_message_id가 실제로 한 번만 설정되고 변경되지 않으므로(포스트가 Discourse 웹 UI에서 생성되었는지, 아니면 수신 이메일을 통해 생성되었는지에 따라), 토픽 ID를 다시 도입하는 것도 고려해볼 만합니다.
Message-ID에 다시 토픽 ID를 추가할 예정이므로 이제 이 기능은 필요하지 않을 것 같습니다.
아, 이걸 봐야 했군요:
most_recent_post = referenced_posts.first
most_recent_post_message_id = Email::MessageIdService.generate_or_use_existing(most_recent_post)
@message.header["In-Reply-To"] = most_recent_post_message_id
어쨌든 기존 코드는 이미 유효합니다. 전적으로 당신에게 맡기겠습니다.
실제로 이 부분은 확신이 서지 않습니다. 직감적으로 Message-ID에 토픽 ID를 포함하고 싶지 않다는 느낌이 듭니다. 포스트 ID만 있으면 매우 간단해지니까요. 대신 다음을 시도해 보겠습니다:
실제로 이미 존재하며, 여기에서 제거합니다:
그냥 그대로 두어도 무방하며, 시각적 디버깅에 도움이 됩니다!
저한테는 괜찮습니다. 다만 웹에서 특정 게시물의 UI나 URL에 post.id가 명확히 드러나지 않아서, 이메일 메시지 헤더를 게시물과 연결하는 것이 특히 어려웠습니다. 추가 컨텍스트 헤더에 해당 정보가 포함된다면 그 또한 충분히 좋습니다.
감사합니다.
Cameron
간단히 연락드립니다. PR이 꽤 오랫동안 조용하네요. - Cameron
캐머런, 안녕하세요. 회사 모임에 참석했고, 지난 2주 동안 휴가 중이었어요. 오늘 겨우 업무 리듬을 찾은 상태입니다. 이번 주에 병합되지 않으면 다음 주에는 반드시 병합될 거예요. 지연된 점 죄송합니다!
Martin Brennan님이 Discourse Meta를 통해 2022년 9월 20일 00:17에:
Hi Cameron, I’ve been at our company meetup then on vacation for the
last 2 weeks, just getting back into the swing of things today. If it’s
not merged this week then it will definitely be merged next week.
Apologies for the delays!
사과하실 필요 없습니다. 부재중이셨다는 점은 알고 있었고, 정확한 시기나 귀환 일정이 어떻게 될지 확신이 없었습니다. 그리고 현재 계신 곳에서는 아직 월요일일 수도 있겠네요 
감사합니다,
Cameron Simpson cs@cskk.id.au
방금 PR을 병합했습니다. 오늘 늦은 시간에 Python 포럼 배포를 시도해 보겠습니다. 그러면 여러분이 본격적으로 사용하실 수 있을 것입니다.
Martin Brennan님이 Discourse Meta를 통해 2022년 9월 25일 23:29에:
방금 PR을 병합했습니다. 오늘 늦게 Python 포럼을 배포해 보려고 하니, 그때부터 본격적으로 사용하실 수 있을 겁니다.
정말 훌륭하겠습니다. 감사합니다, Cameron.
완료되었습니다. 문제가 발생하면 이곳에 알려주세요 
감사합니다. 어떻게 보이는지 알려드릴게요. 카메론