Hello!
I want to change user groups permissions, for example:
Admin Group - all permissions
Co Admin - can do anything but cannot open some sections on admin pane
How to do that? Thanks!
That’s not possible by default since admins have unrestricted access to all the sections of the forum. Depending on what kind of permissions you want to revoke, maybe demoting them to moderator can be helpful?
Moderator cannot create a categories and i want that
Mods can create categories if you enable the moderators_create_categories settings in your discourse admin.
Where i find that? I looked through all the categories in the admin panel and did not see anything that I could assign to moderators.
*Is there something like moderators_create_themes?
Go to admin > Settings
Then search for the keyword moderators_create_categories
Is your Discourse up to date?
What you are asking is, "Is there something like ‘moderators can crash the whole site by making a broken theme?’ ". I’m pretty sure that the answer is going to be “No.”
You could install a remote theme hosted in github that a moderator could change, but an admin would still need to pull in the changes.
You do not know who will tinker with the themes, how can you make that statement?
I asked this question because there are no groups with custom rules like it said above.
My point is that if you trust someone enough to change themes then you can make them an admin.
If you would like to allow non-admins to modify themes or otherwise change what a moderator can do you’ll need a custom plugin.
Not in my current scenario. We have UX and Design teams and they are only responsible for that area, so only access to the themes would be necessary.
저희도 동일한 사용 사례가 있습니다. 웹 디자이너 등 외부 계약업체에게 이 기능을 부여하고 싶은데, 전체 관리자 권한을 주면 사적인 경영 논의 내용까지 접근할 수 있어 바람직하지 않습니다.
웹 디자이너가 전체 관리자 권한 없이 변경 사항을 제출하거나 시도할 수 있는 워크플로우가 있으면 좋겠습니다.
@Joaquin_Menchacha 안녕하세요.
이 주제에 대한 게시글과 상기해 주셔서 감사합니다.
저희도 향후 관리자 권한 설정을 일부 개선할 계획(희망)입니다.
예를 들어, yml 컨테이너 파일의 변수로 설정되며 사이트 전체 백업 다운로드와 같은 특정 관리자 작업을 특정 사용자(userid)에게만 제한하는 플러그인(언젠가)에 관심이 있습니다.
이 플러그인 아이디어는 "제 담당"이며, 기회가 되면 더 자세히 살펴보겠습니다. 지금까지는 코드를 보고 이 아이디어의 실현 가능성을 검토하는 첫 단계조차 밟지 못한 상태입니다.
여기서 해결책을 찾으신 분이 계신가요?
저도 일부 직원에게 테마 접근 권한과 하우스 광고 접근 권한을 부여하고 싶은 동일한 사용 사례가 있습니다.
가장 쉬운 방법은 사람들을 신뢰하고 관리자나 모더레이터로 지정하는 것입니다. 완전한 제어 권한을 그들에게 맡기지 않되, 추가적인 접근 권한을 부여하고 싶다면 플러그인이 필요합니다.
그들을 믿지 못해서 그런 건 아니에요. 하지만 우리의 위협 모델을 생각하면, 이는 추가적인 공격 표면을 만들어내죠. 만약 해당 사용자가 자신의 보안 부재로 인해 해킹당한다면 어떻게 될까요? 변수가 정말 많아요.
그럼 플러그인 옵션을 검토해 보겠습니다.
동의합니다. Discourse에는 커스터마이징을 위한 추가적인 제어 기능이 필요합니다. 다른 분들이 언급했듯이, 외부 용역 인력을 고용하여 고급 기능을 사용하면서도 동시에 회원 정보의 보안을 유지할 수 있어야 합니다.
그룹 Moderation(모더레이션)은 어느 정도 기능을 갖추고 있지만, 때로는 전체 Mod(모더레이터)의 모든 기능이 아니라 일부 고급 기능만 필요할 수 있습니다.
확실히 플러그인이 도움이 될 수 있습니다. 하지만 Merge User 플러그인이 코어에 통합된 것처럼, 더 다양한 스태프 유형을 허용하기 위해 더 강력한 Moderator/Admin의 커스터마이징 기능도 코어에 통합되어야 합니다.
여기 있는 다른 분들처럼, 특정 기능(전체가 아님)에 대해 staff와 admin이 접근할 수 있는 것을 명시하는 RBAC(역할 기반 접근 제어)의 추가 계층으로 접근 제어 모델이 개선될 것이라고 동의합니다.
예를 들어, 사이트는 더 많은 관리자(admin)를 추가하고 싶을 수 있지만, 더 작은 범위의 관리자 RBAC 권한을 부여하는 것을 선호할 수 있습니다. 예를 들어, 사이트 전체 백업을 다운로드할 수 있는 권한을 부여하거나 부여하지 않거나, 특정 직원(staff) 작업 로그 파일에 접근할 수 있는 권한을 부여하는 등의 경우입니다. 또한, 사이트는 일부 직원이 관리자나 개발자의 직원 작업을 볼 수 있는 RBAC 권한을 갖지 않도록 보장하고 싶을 수 있으며, 이는 특히 더 “개인적인” 것으로 간주되는 특정 작업에 해당합니다.
모든 사이버 보안 전문가들은 (직접적인 경험을 통해 알고 있듯이) 어떤 조직에 대한 가장 큰 위협이 외부 해커나 공격자가 아니라 "불만족스러운 내부자(disgruntled insider)"라는 것을 배우고 있습니다. 이 기본적인 IT 보안 위험에 대해 의심의 여지가 없으며, 훈련을 받거나 풍부한 현장 경험을 가진 IT 보안 전문가들에게는 잘 확립된 지식입니다. 따라서 "단순히 관리자를 신뢰하라"거나 "직원을 신뢰해야 한다"는 식으로 내부자 위협을 무시하는 것은 IT 전문가들에게 기술적인 해결책이 아닙니다. 아무리 신뢰할 수 있고 오랜 기간 충성해 온 직원이라 해도, 그들의 삶을 변화시켜 "불만족스러운 직원"으로 변하게 할 수 있는 개인적인 문제에 직면할 수 있습니다. 또한, 가장 많은 권한을 가진 직원이 가장 많은 실수를 하는 경향이 있으며, 일반적으로 선의의 직원/관리자 실수는 어떤 해커보다 더 많은 다운타임을 유발한다는 것을 우리는 잘 알고 있습니다.
얼마 전, 저는 우리 사이트를 위해 Discourse의 class Guardian을 수정하는 것을 고려해 보았지만, 해당 클래스를 더 자세히 살펴본 후, Discourse의 RBAC를 강화하기 위한 최소한의 양의 몽키 패치(monkey patch) 코드를 작성할 수 있는 "간단한 해결책"이 있는지 명확하지 않았습니다. 본성이 게으르고 가능한 한 간단한 솔루션을 만드는 것을 선호하는 저로서는, 이 아이디어를 보류하고 다른 “잘 지불되는 고객” 프로젝트로 넘어갔습니다.
그 후, 저는 코드 수준을 한 단계 낮추어 staff와 admin의 일부 기능을 developer로 이전하는 것을 고려해 보았지만, 이 접근법은 너무 많은 몽키 패치를 필요로 하여 당시에는 좋은 아이디어가 아니라고 생각했습니다. 결국, 10개의 패치 대신 1개의 패치로 무언가를 달성할 수 있다면, 당연히 1개의 패치가 더 좋습니다.
아직까지 이 Discourse 코어 부분을 더 깊이 살펴보고 “상대적으로 간단한” 플러그인을 통해 작성할 수 있는 “쉬운” RBAC 플러그인 강화가 있는지 확인할 시간이나 "급한 요구사항"이 없었습니다.
솔직히 말해서, 저는 아직 최고의 Ruby 전문가가 아니고, 대부분 자신을 “Ruby 코더 지망생” 정도로 생각합니다. (LOL) 아마도 이미 간단한 RBAC 플러그인 솔루션이 존재할 가능성이 높다고 확신하지만, 개인적으로는 아직 찾지 못했으며, 훨씬 더 경험 많은 Ruby 개발자가 코드를 빠르게 살펴보고 어떻게 접근해야 하는지 볼 수 있을 것입니다.
제 아이디어는 역할에 기반하여 특정 RBAC 권한을 제한하거나 부여하는 새로운 불리언 사이트 설정을 추가하고, 그런 다음 플러그인 내의 몽키 패치를 통해 해당 불리언 값을 코드의 적절한 부분에 추가하는 것이었습니다. 그러나 앞서 언급했듯이, 저는 "여러 개
@jrgong 님, 안녕하세요.
아마도 잘 알고 계시겠지만, 플러그인을 통해 이 작업을 수행하는 것은 어렵지 않습니다.
기본적으로, Discourse가 이메일 주소를 통해 개발자를 정의하는 방식과 유사하게, 이메일, 사용자 이름 등으로 구성된 직원 목록을 전역 설정으로 만들 수 있습니다.
그런 다음, 관심 있는 두 가지 사용 사례를 허용하기 위해 일부 패치에 해당 GlobalSettting을 사용할 수 있습니다.
첫 번째 사용 사례인 '직원으로 테마 커스터마이징’은 코어 원키(monkey) 패치를 통해 비교적 쉽게 구현할 수 있다고 생각합니다.
두 번째 사용 사례의 경우, 많은 작업 없이 이 플러그인을 포크하여 이 플러그인의 라우트 접근 제약 조건(그리고 기타 필요한 변경 사항)을 재설계할 수 있습니다:
애드 플러그인의 제약 조건은 플러그인 내부에 내장되어 있으므로, 자체 RBAC(역할 기반 접근 제어)에 따라 허용된 직원이 해당 플러그인의 특정 부분에 접근할 수 있도록 해당 코드를 실제로 수정하는 것이 좋습니다.
즉, 코드를 작성할 의향이 있다면 두 가지 요구 사항 모두 구현 가능합니다. 물론 Marketplace 채널에서 숙련된 Discourse 플러그인 개발 전문가에게 도움을 요청할 수도 있습니다.
고맙습니다 @neounix, 의견 정말 감사드립니다! 개발자에게 맡겨서 처리하겠습니다
수정: 플러그인을 포크하는 방법 말고는 다른 방법이 없나요?
그리고 babble 채팅 플러그인에 대한 접근은 어떻게 되나요? 그것도 포킹이 필요할까요?
우리는 소프트웨어에 대해 이야기하고 있습니다.
어떤 일을 처리하는 방법은 항상 여러 가지가 있습니다.
저는 제 추천 사항을 드렸습니다.
