具体的に、どのような状況で管理者またはシステムアカウントが「個人メッセージの確認」ログエントリをトリガーするのでしょうか?
管理者が実際に他のユーザーの個人メッセージを確認した場合だけでなく、スレッドが逸脱や挑発的な投稿などの理由で個人メッセージに分割された際にも発生するようです。
他にどのような状況でこの「個人メッセージの確認」ログエントリが記録されるのでしょうか?
当フォーラムではこの特定のログエントリタイプを巡って緊張が高まっているため、これを明確に特定する必要があります。
具体的に、どのような状況で管理者またはシステムアカウントが「個人メッセージの確認」ログエントリをトリガーするのでしょうか?
管理者が実際に他のユーザーの個人メッセージを確認した場合だけでなく、スレッドが逸脱や挑発的な投稿などの理由で個人メッセージに分割された際にも発生するようです。
他にどのような状況でこの「個人メッセージの確認」ログエントリが記録されるのでしょうか?
当フォーラムではこの特定のログエントリタイプを巡って緊張が高まっているため、これを明確に特定する必要があります。
PM に含まれていない管理者が PM の内容を確認できる場合は、いつでもログに記録されるべきだと考えられますが、これで合っていますか? @techAPJ
そのため、ログに個人メッセージを読み取ったとして ‘system’ などのサービスアカウントが時折表示されるのでしょうか?おそらく、何らかの種類のクリーンアップを行う際のことではないでしょうか?
管理者がトピックをプライベートメッセージに変換すると、操作が成功した直後にブラウザが自動的にその PM を読み込みます。
プライベートメッセージの参加者は、スタッフのアクションログ(おそらく参加者に提供されているもの)のタイムスタンプを確認することで、管理者がどの投稿を閲覧できたかを正確に把握できます。この場合、閲覧できたのは以前公開されていた投稿のみです。
不思議ですね。meta でも同様の現象が起きていることを確認しました。
これはトピックの最初の投稿が削除された際に発火するwebhooksに起因しています。ログは webhook の存在チェックの前に作成されるため、webhook がトピックの内容を受け取らなかった場合でもログが記録されてしまいます。
cc @vinothkannans - これは FIX: Generate webhook payloads before destroy events (#6325) · discourse/discourse@8430ea9 · GitHub です。对此有什么修复方案でしょうか?TopicView.new() が PM の閲覧アクションを作成しています。
このコミットにより、問題が解決します
それは正しいと思います。