관리자 권한이 server admin 역할과 chief moderator 역할을 혼동하는 것으로 보입니다.
저희의 사용 사례를 바탕으로 질문드립니다. IT 부서가 Discourse 서버 인스턴스를 설정하지만, Discourse 내부 콘텐츠의 운영이나 개발에는 책임도 관심도 없습니다.
server admin가 담당해야 할 옵션(예: SSL 구성)과 chief moderator가 수행하는 작업(예: 카테고리 설정)을 분리하는 방법이 있을까요?
예를 들어 SSL 설정을 담당하는 IT 관리자는 Discourse 계정이 필요하지 않으며, 서버에 대한 접근 권한만 있으면 됩니다. 또한 대부분의 IT 관련 설정은 app.yml에서 환경 변수로 설정할 수 있으므로, Discourse의 웹 부분에는 IT 접근 권한이 필요하지 않습니다.
이렇게 하면 ‘수석’ 모더레이터는 단순히 Discourse 관리자/모더레이터로 활동하면 됩니다.
@Falco 님, 감사합니다.
그렇다면 관리자 권한 내에 등급을 둘 수 있을까요? 예를 들어 adminType2는 XYZ는 수행할 수 있지만 JKL은 수행할 수 없는 경우 말입니다.
아니요, 세밀한 커스터마이징 권한 시스템은 없습니다.
@Falco, 그 점은 다소 안타깝게 생각합니다.
Email 섹션에는 서버 관리자가 신경 써야 할 사항이 있지만 최고 모더레이터에게는 실제로 필요하지 않은 필드들이 몇 가지 있습니다. 예를 들어, 이메일 계정과 비밀번호, pop3 폴링에 사용할 포트 번호, 기타 관련 설정 등이 있습니다.
또한, 서버 부하에 영향을 줄 수 있는 Admin 매개변수도 여러 가지가 있습니다. 서버 관리자가 이러한 설정도 관리하고 싶어 할 수 있다는 점은 쉽게 예상할 수 있습니다. 간단한 예로, 이미지와 첨부 파일의 최대 파일 크기가 있습니다. 모든 Admin 옵션을 살펴본 결과, 최고 모더레이터가 아니라 서버 관리자가 제어해야 할 설정이 매우 많습니다.
제 질문의 요지는, 백엔드 팀에 의해 공개용 팀의 작업이 쉽게 방해받을 수 있다는 점이며, 양쪽 모두 정당한 우려를 가지고 있습니다.
혹시 Admin 패널에서 특정 매개변수에 대한 접근 권한을 제거하는 최고 모더레이터용 템플릿이 있을까요?
해당 설정을 app.yml의 env 섹션에 추가하면 UX에서 표시되지 않습니다.
예시를 확인하려면 업로드를 위한 객체 저장소 사용 (S3 클론)을 참고하세요. 이 방식으로 모든 사이트 설정을 오버라이드하고 숨길 수 있습니다.
@pfaffman 감사합니다.
외부 저장소에 대한 링크를 확인해 보았는데, 신규 사용자에게는 다소 혼란스럽습니다.
제가 이해한 바로는, 말씀하신 내용이 두 가지입니다. (1) 관리자 영역에서 확인되는 모든 설정은 app.yml 파일에서 구성할 수 있으며, (2) app.yml 파일에서 구성한 옵션은 관리자 영역에 표시되지 않는다는 것입니다.
이렇게 이해한 것이 맞습니까?
추가 질문입니다. 현재 관리자 설정을 파일로 내보낸 후, 이를 app.yml 파일에 포함할 수 있나요?
잘 이해하고 있는 것 같네요. 환경 변수 값은 직접 생성해야 합니다.