いいえ、そのアイコンは見えています。
それとも、この部分が見えないということですか? [返信アイコン+親投稿者] 後者の場合、返信アイコンは、返信している投稿がトピックのさらに上にある場合にのみ表示され、単に前の投稿である場合には表示されません。
ああ。しかし、私は、メールの非フォーラム利用者として、これをインスタントメッセージレイアウトとして考えていない(おそらく)ため、すべての返信にそのインジケーターが表示されることを期待していました。したがって、私の期待は、あなたが選択したことと異なります。
cameron-simpson:
web multireplies only get one msg-id in the in-reply-toああ、これは必要だとは思いませんでした。
必要ではありません。「サービス品質」と考えてください。あなたは明示的に次のように記述します。
@message.header['In-Reply-To'] = referenced_post_message_ids[0] || topic_canonical_reference_id
そして、そこで [0] を削除するだけで済みます。クライアントは1つのメッセージIDを使用するか、自由に何か非常に奇妙なことを行うことができます。すべて有効です。
したがって、Web経由でN個の投稿に返信する場合、それらの投稿のMessage-IDはすべて
In-Reply-Toヘッダーに表示され、ReferencesはOPから単一の親までのスレッドの現在のロジックに従います(この場合、最も最近作成された投稿を単一の親として選択しますか)?
「〜べき」というのは強い言葉です。もし容易に入手できるのであれば、すべてのメッセージIDを含めることができます。義務ではありませんし、コードは現状のままでも有効です。
cameron-simpson:
users do not get email copies of their own posts (email or web), would be nice to have an option in prefs for thisはい、これは意図的に、すでに「見た」ものを送信しないように設計されています。より多くのユーザーからの要望があるかどうかを確認するために、これを別のTODOに切り出すことができます。
はい。私自身も、投稿がリスト/フォーラムに届いたことを知るために、それが好きです。メールは非常にキューベースであり、一部の(咳、巨大なオーストラリアの電話会社、咳)ISPメールハンドラは非常に…信頼性が低く、遅く、などなどです。時々、他の人がこれを望んでいるのを見かけました(リストでは、しかしこれは実質的に私たちがここで話しているモードです)。そのようなオプションのデフォルトはおそらくfalseであるべきです。
オタクとして、私は少なくともフィルタリングされていないフィードを取得できるようにしたいので、自分でポリシーを決定できます。
cameron-simpson:
web msg-ids seem to be forum post.id, would be nicer if topic.id/in-topic.id for easier tracing in headersトピックIDの問題は、それがもろすぎ、十分に特異的/一意ではないことです。また、投稿がトピック間で移動された場合、少し混乱するように見えるでしょう。
Message-IDは実質的に不透明/一度設定されるものであることを考えると、同じメッセージIDを再発行する可能性がある場合を除き、それを問題とは見なしません。すべてのカウンターが厳密に単調増加であれば、そのようなことは起こらないはずです。post.id、例えば98をトピック/投稿、例えば59/1と一致させるのが非常に面倒だと感じただけです。代わりに98の代わりにcategory.id/topic.id/post-in-topic.idのようなものがあると便利でした。
メールにカスタムヘッダーを含めることができるかもしれません。例えば、
X-Discourse-Topic-IDなど(許可されている場合)で、視覚的な追跡を容易にすることができますか?
それも十分でしょう。これはデバッグヘッダー側の単なる利便性です。
Cheers,
Cameron