And by that you mean that you would have it… because I can use it for almost everything already, banking, taxes, even here 
이 기능을 개발하고 있습니다! (적어도 최선을 다하고 있어요)
제 생각은 Admin > Site Settings > Security의 Moderators view emails 라디오 선택 항목 아래에 옵션을 추가하는 것입니다. 원래 기능 요청에 따라, 이 선택자를 Moderator의 뷰에서 IP 주소용 CSS를 켜거나 끄는 플래그로 사용하는 대신, 백엔드에서 현재 사용자의 역할이 moderator인지 확인하고 User 모델의 IP 필드에 대한 데이터베이스 쿼리를 방지할 수 있습니다. 마지막으로, 사용자 프로필/로그 UI에서 IP 선택 항목을 숨기는 것입니다.
매우 고수준의 개요이지만, 해결책을 이렇게 생각하고 있습니다. 관심 있으신 분들을 위해 이번 주에 PR을 올려서 의견을 받을 예정입니다!
7개의 좋아요
리뷰를 위해 PR이 올라왔습니다! FEATURE: add option to hide IP addresses from moderators - Pull Request #31456 - discourse/discourse - GitHub
7개의 좋아요
이것이 3월 초에 승인된 것을 확인했습니다. 하지만 이후 병합되지 않았고, 이제 충돌이 발생하고 있습니다. 3월에 병합되지 못한 이유는 무엇이었나요? 현재 상태는 어떻게 되나요?
4개의 좋아요
VPN이나 프록시 서버를 사용하는 것도 고려해 보세요. 운영자(오프)가 CSS를 사용해 특정 코드만 적용되도록 하는 간단하고 즉흥적인 해결책도 제시했는데, 이 방법은 관리자(Admin)에게는 적용되지 않습니다.
자체 호스팅을 하고 있다면, 모드가 서버 측과 클라이언트 측으로 구별되도록 하는 작은 플러그인을 직접 만들어도 됩니다. 다만, 전체 권한을 가진 수석 관리자(Full Moderator)는 신뢰할 수 있을 정도로 권한이 크기 때문에 우려할 필요가 없습니다. 그리고 만약 우려가 있다면, 플래그를 관리할 수 있는 카테고리 모더레이터(Category Moderator)를 활용할 수 있습니다. 이들은 침묵(Silence) 또는 정지(Suspend) 권한은 없지만 플래그 관리만 가능합니다.
@RGJ 님은 특정 카테고리에 대한 부분적인 침묵/밴(Silence/ban)을 확장할 수 있는 플러그인을 가지고 있습니다. 또한 카테고리 zmod 기능을 확장하는 플러그인도 있었지만, 현재는 더 이상 유지보수되지 않습니다. 따라서 자체 호스팅을 하고 예산이 있다면, 해당 플러그인을 부활시키거나 관리자의 IP 주소를 숨기는 기능을 개발하는 것을 Marketplace 채널에서 후원(Sponsor)할 수 있습니다.
Discourse Meta가 사용자 정의 #customization:플러그인, #customization:테마, #customization:테마-컴포넌트를 지원하는 이유입니다.
이 요청을 플러그인으로 구현하면 가장 높은 수준의 보안을 위해 서버 측이 변경됩니다. 그러나 이론상 테마 컴포넌트(TC)로도 충분할 수 있습니다. Reddit의 모더레이터보다 전체 관리자(full moderators)는 훨씬 더 신중하게 선정되어야 하기 때문입니다.
저는 동의하지 않습니다. 누군가 IP 주소를 악용하려 한다면 그에 맞는 노력을 기울일 것이며, 단순히 외형적으로만 가리는 TC로는 이를 막을 수 없습니다.
기술적/법적 관점에서, IP 주소는 해당 사용자의 장치에까지 전송됩니다.
2개의 좋아요
이것은 전체版主(Full Moderator)가 메인 사이트 스태프라는 점으로 돌아가게 됩니다. 그들을 신뢰할 수 없다고 생각한다면, Reddit版主처럼 민감한 정보에 접근할 수 없도록 카테고리版主(Category Mod)로 승격하세요.
만약 전체版主가 사이트의 통제를 우회하는 성향이라면, 그들을 신뢰해야 할까요?
안전 모드(Safe Mode)를 관리자(Admin)만 사용할 수 있도록 설정할 수 있나요, 아니면 해당 제한 기능은 스태프에게만 적용되는 것인가요?
진정으로 신뢰할 수 있는 스태프라면 사이트 기능과 보안에 타격을 주지 않을 것이라고 신뢰할 수 있어야 합니다.
카테고리版主 확장 플러그인의 경우, Sam이 카테고리版主에 더 많은 선택지를 추가하는 데 반대하지 않는다고 말한 기억이 납니다.
개인적으로, 사용자가 게시를 무음 처리하고 BAN하는 옵션을 추가하는 카테고리 플러그인은 코어에 추가되어야 한다고 생각합니다. 또한 Reddit 스타일의 기능을 더 많이 갖추어 Reddit 테마와의 일관성을 높이는 데에도 도움이 될 것입니다.
Eve. 개인적으로 전체版主에게는 더 세밀한 제어 권한이 있어야 한다고 생각합니다. 하지만 카테고리版主에게 더 많은 옵션이 추가된다면 그것만으로도 충분히 좋을 수 있습니다.
관리자(Admin)에게도 특정 관리자 기능에 접근해야 하지만 사이트 소유자가 일부 사항을 더 높은 수준의 직원에게만 제한하고 싶어하는 경우를 위해, 세밀한 제어 옵션이 필요할 수 있습니다.
1개의 좋아요
물론, 당신은 옳습니다. 하지만 이것은 단순히 신뢰의 문제가 아닙니다. GDPR(일반 데이터 보호 규정)과 기타 개인정보 보호 법률은 또한 PII(개인식별정보)가 노출되는 범위를 최소화하도록 요구합니다. 즉, 누군가가 해당 데이터를 볼 필요가 없다면, 그 데이터를 소유할 수 있어서는 안 됩니다.
당신은 문제를 복잡하게 만들고 있습니다:
- 이것이 TC(테마 커스텀)로 구현된다면, IP 주소는 항상 모더레이터에게 보일 수 있으며, 안전 모드 사용 여부와 무관합니다.
- 이것이 올바르게 플러그인으로 구현된다면, IP 주소는 절대 모더레이터에게 보이지 않으며, 안전 모드 사용 여부와 무관합니다.
3개의 좋아요
즉, 안전 모드에서도 비활성화되지 않는 플러그인을 가질 수 있다는 말인가요? 옵션 중 하나가 모든 플러그인과 테마/TC를 비활성화하지 않나요?
그렇다면 이 주제에서 언급된 대로 PR의 보안이 최선일까요?
즉, 서버 측 수정 사항은 안전 모드에 영향을 받지 않습니다(플러그인이 명시적으로 처리하지 않는 한).
코어에 대한 PR은 항상 플러그인보다 좋습니다! 하지만 보안 측면에서는 큰 차이가 없었을 것입니다.
해당 PR을 살펴봤는데, 왜 병합되지 않았는지 이해가 되지 않습니다…? @featheredtoast ?
5개의 좋아요
설명해 주셔서 감사합니다.
2개의 좋아요
지연된 점 사과드립니다. 현재 수정 중이며 곧 병합하겠습니다.
7개의 좋아요
PR이 최신 Discourse 기준으로 업데이트되어 코어에 병합되었습니다. 
6개의 좋아요
Discourse에 이 기능을 추가해 주셔서 감사합니다. 저희에게는 관리자에게 위임하는 과정을 단순하게 유지하면서 더 쉽게 처리할 수 있게 해 주었습니다.
또한 이 기능을 구현해 주신 @Beznet님께도 감사드립니다. 정말 감사한 일입니다. 
3개의 좋아요
이 주제는 12일 후 자동으로 닫혔습니다. 더 이상 새로운 답변을 작성할 수 없습니다.