봉투를 클릭하여 수신된 이메일을 확인하는 기능은 스태프와 자신의 게시물을 보는 일반 사용자 모두에게 작동해야 합니다. 그러나 스태프가 아닌 사용자가 자신의 게시물을 보려고 하면 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개의 좋아요
무엇을 부르지 않는 것에 대해 입니다. 관리자로 있을 때 이메일 문제를 디버깅하는 데 이 방법을 정말 많이 사용했는데, 어디서든 moderators나 일반 사용자로서 자신의 메시지를 확인한 적은 한 번도 없습니다. 
1개의 좋아요
풀 리퀘스트는 여기입니다: Disallow access to raw email for non-staff users - Pull Request #17569 - discourse/discourse - GitHub
2개의 좋아요
이 pull request가 (조용히) 닫힌 것을 확인했습니다. is_staff?만 포함된 1줄 함수를 어떻게 테스트해야 하는지 정말 모르겠어서 그런 것 같다는 추측을 합니다.
향후 이 PR이 병합될 예정인지 알려주시면 감사하겠습니다. 병합되지 않을 경우, 이 GDPR 문제를 해결하기 위해 플러그인을 직접 만들어야 합니다…
클라이언트 측에 테스트가 없다는 점은 어느 정도 이해할 수 있지만, API 측 테스트는 매우 간단해야 합니다. 포스트 객체와 사용자 객체를 생성한 후, 포스트가 삭제된 경우 사용자가 원본 이메일을 볼 수 없는지 가디언 테스트에서 확인하면 됩니다.
PR이 닫힌 이유를 파악해 보겠습니다.
다만 이는 동작 변경입니다. 버그를 수정하는 대신 해당 기능을 제거하는 방향으로 간 이유가 궁금합니다.
2개의 좋아요
누군가의 실수로 닫힌 것 같습니다. 죄송합니다. 다시 열었습니다.
이건 분명 이상한데요. 의도적으로 닫히게 된 것 같지 않고, 제가 닫은 것도 아닌 것 같습니다. 적어도 의도적으로 그런 일은 없었고, 제가 알고 있는 한 그런 일은 없었습니다. 어쨌든 곧 PR에 후속 조치를 하겠습니다.
PR의 상태가 뭔가 이상합니다. Github의 버그일까요? 
1개의 좋아요
마침내 닫힌 건 정말 이상했어요. 행위하는 사용자가 없었고, 나도 알림을 받지 못했거든요.
고의가 아니었다니 다행이네요!
혹시 제가 오해한 건가요…?
2개의 좋아요
오래 기다리게 해서 죄송합니다. PR이 병합되었습니다.
5개의 좋아요