말씀하신 데에 동의하지만, ‘작은’ 드라마가 오히려 좋을 수 있다고 생각합니다. 사람들이 개인 또는 제3자의 데이터를 관리하고/또는 보호하는 것이 무엇을 의미하는지(사회적 책임이 수반되므로) 이해하고 있기 때문이죠.
경청해 주셔서 감사합니다. 저희 프로젝트에 Discourse를 잘 선택했다고 확신할 수 있습니다. 그리고 물론, 당신의 PR을 전적으로 감사히 생각합니다 
3개의 좋아요
저 설정인 allow_allow_impersonation은 접근을 제한해야 할 것 같아요. 너무 강력한 권한이거든요! 다른 설정으로 대체하는 건 어떨까요? 
7개의 좋아요
모든 것을 지배하는 단 하나의 플러그인 링!
Procourse Installer가 더 잘 지원되지 못한 것은 정말 안타깝습니다.
아니 아니, 적어도 콘솔이나 소스 코드에는 있어야 해. 이 설정을 허용하고 쓰는 게 너무 유혹이거든. 잠깐, 근데 나도 콘솔에 접근할 수 있잖아. 
1개의 좋아요
참고로, 모든 관리자가 콘솔에 접근할 수 있는 것은 아닙니다.
관리자가 일반적으로 시스템이나 Discobot을 사칭할 수 없도록 하는 것과 매우 유사한 개념이라고 생각합니다.
5개의 좋아요
어제 저는 특정 사용자만 영향을 받은 버그(프로필에 잘못된 시간대가 설정된 경우)를 찾기 위해 해당 사용자로 위장해야 했습니다.
관리자를 신뢰하지 못한다면, 사용자로 위장하는 것은 가장 작은 걱정거리일 뿐입니다.
4개의 좋아요
앞서 언급했듯이, 어떤 관리자에게 접근 권한을 부여할지 제한할 수 있는 옵션이 있는 것은 나쁜 일이 아닙니다. 하지만 @sam은 이를 원하는 사람들을 위해 마음의 평화를 줄 수 있는 간단한 수정 사항을 적용했습니다. 이 수정 사항은 현재 방식을 선호하는 사람들에게는 영향을 미치지 않습니다.
이번 논의에서 가장 큰 문제는 타협점을 찾기보다는 장단점을 종합적으로 고려하지 않고 터널 시야(단일 관점)에 갇혀 있었다는 점입니다. 개인적으로 Sam의 PR은 운영자(Op)의 요청 사항을 구현하고, 원하면 추가적인 계층을 도입할 수 있도록 하여 모두에게 적합한 타협점을 제시한다고 생각합니다.
3개의 좋아요
스태프가 이 주제를 닫아 주실 수 있을까요?
매우 단순하고 명확하며 단점이 없는 핵심 솔루션이 제시되었는데도 불구하고, 그쪽에서는 여전히 의미 없는 내용만 계속되고 있습니다.
슈퍼관리자 > 관리자 > 모더레이터 > 레벨 4 구조는 커뮤니티에는 매우 좋은 선택이지만, 개별 개발자에게는 그렇지 않습니다.
그리고 우리가 이야기하고 있는 대상은 개별 개발자가 아닙니다
5개의 좋아요