メール受信トレイを表示するために封筒をクリックする機能は、スタッフと自分の投稿を表示しているユーザーに対して機能するはずです。しかし、スタッフではないユーザーが自分の投稿を表示しようとすると、JavaScriptエラーが発生します。ユーザーは、手動で要求された場合に基になるJSONを表示できます。
スタッフユーザーの場合は機能します。
「いいね！」 4
テストサイトの非スタッフユーザーでも同様のエラーが発生することを確認しました。「Uncaught Error: Failed to create an instance of ‘controller:raw-email’. Most likely an improperly defined class or an invalid module export」です。
対応が必要な件としてマークされました。 
「いいね！」 4
いいですね！ご指摘ありがとうございます。これはごく軽微な問題なので、pr-welcome を付けます。モデレーター以外にメール情報をすべて公開しないという、ごく簡単な修正には賛成です。メール情報をすべて公開することについては、まだ判断しかねています。
「いいね！」 3
何も呼び出さないこと。管理者としてメールの問題をデバッグするために何度も使用しましたが、モデレーターまたは通常のユーザーとして、どこでも自分のメッセージを見たことはありません。 
「いいね！」 1
「いいね！」 2
このプルリクエストは（サイレントに）閉じられたようですが、is_staff? のみを含む単一行関数のテスト方法が正直なところわかりません。
将来的にマージされる予定があるかどうか教えていただけますでしょうか。もしそうでない場合は、このGDPRの問題を解決するためにプラグインを作成する必要があります。
クライアント側のテストがないことはある程度受け入れられますが、API側のテストは非常に簡単であるはずです。投稿オブジェクト、ユーザーオブジェクトを作成し、ガーディアンテストで投稿が削除されたときにユーザーが生メールを表示できないことを確認します。
PRがクローズされた理由を解明しようとします。
ただし、これは動作の変更です。バグを修正するのではなく、機能を削除することになった理由に興味があります。
「いいね！」 2
誤ってクリックされた可能性がございます。申し訳ございません。再オープンしました。
これは確かに奇妙です。意図的に閉じられたとは思えませんし、私が閉じたわけでもありません。少なくとも意図的ではなく、私の知る限りでは。いずれにせよ、すぐにPRのフォローアップを行います。
PRの状態に何かおかしい点があります。GitHubのバグでしょうか？ 
「いいね！」 1
終了処理は、アクティブなユーザーがおらず、通知も受け取らなかったため、非常に奇妙でした。
意図的ではなかったと聞いて安心しました！
ここで誤解していたのかもしれませんね…?
「いいね！」 2
お待たせして申し訳ありません。PRはマージされました。
「いいね！」 5