martin
(Martin Brennan)
2022 年 8 月 23 日午後 10:47
67
親投稿へのリンクにはいくつかの異なる方法があり、関連付けはPostReplyテーブルを通じて保存され、reply_post_idは返信を行っている投稿を表し、post_idは親を参照します。受信メールはこれらをリンクするためにIn-Reply-Toを使用し、Discourse UIから複数の投稿を引用すると複数のPostReplyレコードが作成され、単一の投稿で「返信」ボタンを使用するとPostReplyレコードの作成に使用されます。
はい、すみません、それを指摘すべきでした。add_identification_field_headersはもう使用されず、すべて新しいコードであるadd_experimental_identification_field_headersにあります。コード自体にコメントをいただきありがとうございます!今日中に目を通します。
martin
(Martin Brennan)
2022 年 8 月 23 日午後 11:44
70
@cameron-simpson 申し訳ありませんが、PR の以前のコミットを確認された可能性があります。コードをリベースし、テストサイトでテストしている最新のコードをすべて含む単一のコミットになるように再度プッシュしました。コミットメッセージが役立ち、論理的であることを願っています。
References については、ユーザーが投稿に返信している場合、OP から親投稿までの Message-ID の完全なチェーンを順に使用します。たとえば、これらの投稿がすべて直接の返信チェーンである場合:
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
その場合、最後の投稿の 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> となります。
これが正しくない場合はお知らせください。修正します。
「いいね!」 3
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-To Message-ID は discourse/post/500@test.site> (OP) となり、References は OP である discourse/post/500@test.site> となります。
すべて正しいです。
よろしくお願いいたします。
Cameron Simpson cs@cskk.id.au
「いいね!」 1
martin
(Martin Brennan)
2022 年 8 月 24 日午前 1:25
72
Cameron Simpson:
これはすべて正しいです。
ありがとうございます。また、PostReply レコードに基づいて References チェーンを再作成するためにデータベースにアクセスする必要があることも言及するのを忘れました。最新のコミットで確認できます。
martin
(Martin Brennan)
2022 年 8 月 24 日午後 11:28
73
@cameron-simpson 来週、このコードの内部レビューを開始したいと思います(また、私が作成したものの一般的な最終調整も行いたいと思います)。なぜなら、私は3日に休暇を取るからです。そうすれば、レビューが完了すればマージでき、戻ってきたらデプロイできます。さらにフィードバックがあれば、それまでに知らせてください。そうでなければ、すべて問題ない(昨日のテストでは問題ないように見えました )とみなします。
「いいね!」 1
ほとんど問題ないと思います。ヘッダーのほとんどを手作業で確認した際のメモを以下に示します。
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
要約すると、不正なヘッダーは見つかりませんでしたが、上記のいくつかの不備に注意してください。
更新されたコードを確認する時間はまだありませんが、機能的には問題ないようです。
ありがとうございます。
Cameron
「いいね!」 1
martin
(Martin Brennan)
2022 年 8 月 25 日午前 12:41
75
キャメロンさん、ありがとうございます!
もう少し詳しく教えていただけますか?これが見えないということでしょうか?
それとも、この部分が見えないということでしょうか?後者の場合、返信先の投稿がトピックのさらに上にある場合にのみ、矢印付きの返信を表示します。直前の投稿だけでは表示されません。
ああ、これは必要ないと思っていました。ウェブでN件の投稿に返信した場合、それらの投稿のMessage-IDはすべてIn-Reply-Toヘッダーに表示され、ReferencesはOPから単一の親(この場合は最も新しく作成された投稿を単一の親として選択します)までの現在のスレッドロジックに従うということですか?
はい、これは意図した動作です。すでに「見た」ものを送信しないようにしています。これについては、他のユーザーからの要望があるか確認するために、別のTODOとして切り出すことができます。
トピックIDの問題は、もろすぎ、十分に特定/一意ではないことです。また、投稿がトピック間で移動された場合に少し混乱するように見えるでしょう。ヘッダーでの追跡を容易にするために、カスタムヘッダー(許可されている場合)をメールに含めることはどうでしょうか。例えば、X-Discourse-Topic-IDのようなものです。
「いいね!」 2
いいえ、そのアイコンは見えています。
ああ。しかし、私は、メールの非フォーラム利用者として、これをインスタントメッセージレイアウトとして考えていない(おそらく)ため、すべての返信にそのインジケーターが表示されることを期待していました。したがって、私の期待は、あなたが選択したことと異なります。
Martin Brennan:
ああ、これは必要だとは思いませんでした。
必要ではありません。「サービス品質」と考えてください。あなたは明示的に次のように記述します。
@message.header['In-Reply-To'] = referenced_post_message_ids[0] || topic_canonical_reference_id
そして、そこで [0] を削除するだけで済みます。クライアントは1つのメッセージIDを使用するか、自由に何か非常に奇妙なことを行うことができます。すべて有効です。
「〜べき」というのは強い言葉です。もし容易に入手できるのであれば、すべてのメッセージIDを含めることができます。義務ではありませんし、コードは現状のままでも有効です。
はい。私自身も、投稿がリスト/フォーラムに届いたことを知るために、それが好きです。メールは非常にキューベースであり、一部の(咳、巨大なオーストラリアの電話会社、咳)ISPメールハンドラは非常に…信頼性が低く、遅く、などなどです。時々、他の人がこれを望んでいるのを見かけました(リストでは、しかしこれは実質的に私たちがここで話しているモードです)。そのようなオプションのデフォルトはおそらくfalseであるべきです。
オタクとして、私は少なくともフィルタリングされていないフィードを取得できるようにしたいので、自分でポリシーを決定できます。
Message-IDは実質的に不透明/一度設定されるものであることを考えると、同じメッセージIDを再発行する可能性がある場合を除き、それを問題とは見なしません。すべてのカウンターが厳密に単調増加であれば、そのようなことは起こらないはずです。post.id、例えば98をトピック/投稿、例えば59/1と一致させるのが非常に面倒だと感じただけです。代わりに98の代わりにcategory.id/topic.id/post-in-topic.idのようなものがあると便利でした。
それも十分でしょう。これはデバッグヘッダー側の単なる利便性です。
Cheers,
Cameron
「いいね!」 4
martin
(Martin Brennan)
2022 年 8 月 25 日午前 1:17
77
それはまだあなたがそこに見ている古いコードです。add_experimental_identification_field_headers だけを見る必要があります。しかし、あなたの言っていることは依然として正しいです。
私たちのインフラストラクチャチームには、この発言を強く支持する人がいます。その人はあなたと似たようなワークフローと見方を持っています
それはもっともなことです。おそらくトピックIDも再導入するでしょう。なぜなら、outbound_message_id は確かに一度設定され、変更されないからです(Discourse Web UIで投稿が生成されるか、受信メール経由で生成されるかに基づいて)。
トピックIDを再度 Message-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
とにかく、既存のものはすでに有効です。すべてあなたの判断次第です。
「いいね!」 2
martin
(Martin Brennan)
2022 年 8 月 26 日午前 1:53
79
I’m actually not sure about this, I’ve got a gut feeling we don’t really want the topic ID in those Message-IDs, just having the post ID makes it super simple. Will try this instead:
martin
(Martin Brennan)
2022 年 8 月 26 日午前 1:56
80
それで結構です。特に、UIや特定の投稿のURLにpost.idが表示されないため、メールメッセージヘッダーと投稿を結びつけるのが難しいと感じました。それを追加のコンテキストヘッダーに含めていただけると、同様に役立ちます。
よろしくお願いいたします。
Cameron
「いいね!」 1
ちょっとした確認です。PRがしばらくの間、静かになっているようです。- Cameron
martin
(Martin Brennan)
2022 年 9 月 20 日午前 12:05
83
キャメロン様
会社の集まりに参加した後、2週間休暇を取っていました。今日から通常業務に戻ります。
もし今週中にマージされなければ、来週には必ずマージされます。遅れて申し訳ありません!
By Martin Brennan via Discourse Meta at 20Sep2022 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
「いいね!」 2
martin
(Martin Brennan)
2022 年 9 月 25 日午後 11:19
85
PRをマージしました。Pythonフォーラムは本日中にデプロイできるようにしますので、本格的に利用を開始してください。
「いいね!」 1
Discourse Meta の Martin Brennan より 2022年9月25日 23:29:\n\u003ePRをマージしました。Pythonフォーラムを後でデプロイして、本格的に使えるようにします。\n\nそれは素晴らしいですね。ありがとうございます、Cameron
「いいね!」 2
martin
(Martin Brennan)
2022 年 9 月 26 日午前 1:51
87
これで完了しました。問題が発生した場合は、ここでお知らせください
「いいね!」 2
ありがとうございます。どのように見えるかお知らせします。キャメロン