오래된 주제를 끌어올리는 것은 예의가 아닌 것 같지만, 더 새로운 주제를 찾을 수 없었습니다. 알아본 내용을 공유해 주시면 감사하겠습니다.
요즘 이 포럼을 아주 다양한 용도로 사용하고 있습니다.
저는 개인적인 목적으로 읽기 전용 카테고리를 생성하는 경향이 있습니다. 이 경우 접근 권한을 가진 사용자는 단 한 명만 두어, 실제 계정을 만들고 싶지 않은 모든 사용자에게 단순하게 접근할 수 있도록 합니다. 때로는 사용자가 계정을 생성하면 쓰기 권한도 부여하게 됩니다. 그런데 이를 위해서는 category_xyz_see와 category_xyz_write 그룹이 필요하다는 것을 깨달았습니다. 글쎄요, 그건 그냥 일이겠지요.
어떤 이유에서인지 보안 설정에서는 그룹만 추가할 수 있고, 결국 사용자가 또 다른 객체임에도 불구하고 직접 추가할 수 없다는 점이 이상하게 느껴집니다.
초대 방식은 시도해 보지 않았습니다. (SSO 뒤에 위치하지만, 아마 지금은 수정되었을 가능성이 높습니다.)
대안으로 태그를 사용해 관련 토론을 그룹화하는 개인 메시지를 사용하는 것이 어떨까요?
다만, 저는 비공개 카테고리에 접근할 수 있도록 특별히 생성된 사용자 계정을 사용합니다.
그 이유는 요즘 사람들이 어딘가에 또 다른 계정을 만드는 것을 정말로 원하지 않기 때문입니다. 따라서 수개월에서 최대 2년 정도만 유지되는 단기적인 정보의 경우, 사이트의 공개 영역에 읽기 권한이 있는 로그인 계정을 사용하거나, 폐쇄된 카테고리에 접근할 수 있는 특정 로그인 계정을 사용합니다.
이 접근 방식은 더 많은 독자를 유치하는 데 도움이 되며, 사이트에서 다른 흥미로운 콘텐츠를 발견한 일부 독자는 실제 사용자로 전환됩니다.
필수 로그인 기능을 통해 사이트가 깔끔하게 유지됩니다.
이것은 누군가가 자신의 Discourse를 어떻게 사용하는지에 대한 사용 사례 시나리오를 제시하는 것일 뿐, 그 이상의 의미는 없습니다. 개발자로서 저는 사람들이 제가 예상하지 못한 방식으로 시스템을 사용할 때 흥미를 느끼곤 합니다.
하지만 필요한 사용자를 추가하여 다른 권한을 가진 또 다른 그룹을 만들면 해결할 수 있으므로 큰 문제는 아닙니다.
생각해 보면, PM의 정의는 개별 액세스 제어가 적용된 토픽입니다. UI에서 서로 다른 위치에 표시되는데, 둘 다 사용한다면 매우 혼란스러울 것입니다.
흥미로운 아이디어라고 생각합니다. 우리는 일반적으로 그룹 사용자에게와 동일한 수준을 제공해 왔습니다. 이번처럼 그 반대인 경우는 처음 보는 것 같습니다.
매우 작은 사이트나 소수의 사람들을 위한 카테고리에서는, 그룹 이름과 함께 사용자 이름을 카테고리 보안 필드에 입력할 수 있는 것이 매우 유용하고 효율적일 수 있다고 봅니다. 하지만 사용자 이름을 많이 추가하기 시작하면 당연히 다루기 어려워집니다.
적어도 프로그래머의 관점에서, 나는 스티븐의 의견에 동의하지 않습니다. 사용자가 있든 그룹이 있든 관계없습니다. 둘 다 객체이기 때문입니다. 제 생각에는 둘은 서로 겹쳐서 매핑되며, 중복될 수 있습니다.
UI에서 혼란스러울 수도 있고, 아닐 수도 있습니다. 중복을 표시할 필요는 없으며, 사용자가 그룹에도 속해 있는 것은 무관합니다(시스템이 알아서 처리하면 되므로).
또한 하위 카테고리가 상위 카테고리 수준의 접근 권한을 가져야 한다는 제한 사항도 발견했습니다. 어느 정도 일리는 있습니다. 전체 구조를 뒤집을 수도 있겠지만, 이 특정 경우에는 오히려 역설적으로 느껴질 것 같습니다.
왜 이런 구조가 필요한지 설명하기 위해 실제 사용 사례를 다시 보여드리겠습니다. 여기서는 모든 적절한 영어 단어를 알지 못할 수 있지만, 사람들은 요점을 이해할 수 있을 거라고 생각합니다.
한 사람이 사망했고, 많은 사람들이 유산에 포함되어 있습니다.
더 쉬운 접근을 위해 읽기 전용 사용자를 생성했습니다(해당 사용자를 "보기 그룹"에 추가).
이미 사이트에 있던 일부 사람들도 그룹에 추가했습니다(로그아웃하고 계정을 전환할 필요가 없도록 하기 위함).
최상위 카테고리에는 공동 정보, 장례식 등의 내용이 포함됩니다.
하위 카테고리 중 하나에는 금전 정보가 포함됩니다(아직 명확하지 않아 모든 문제가 해결될 때까지 모든 사람에게 공개되지 않음). 여기에서 신뢰할 수 있는 남성(유산에 포함되지 않은 사람일 수도 있음)을 추가한다고 해서, 그가 최상위 카테고리에 접근해야 하거나(또는 접근할 수 있어야 하거나) 하는 것은 아닙니다.
약간의 고민을 거치면 좋은 처리 방법을 생각해 낼 수 있다고 확신합니다. 하지만 기본적으로 단일 사용자를 어떤 수준에든 추가할 수 있도록 허용하는 것이 더 아름답고(논리적으로도) 문제를 해결할 수 있습니다.
그리고, 이 모든 것은 추가 그룹을 거의 사용함으로써 달성할 수 있으므로, 아마도 그만한 노력을 기울일 가치가 없을 것입니다.
그룹과 카테고리의 개념은 디스코스에 깊이 내장되어 있으며 많은 부분을 다루기 때문에, 이 부분을 변경할 의향이 있을지 확신할 수 없습니다. 이는 매우 큰 변경 사항이 될 것입니다.
그럼에도 불구하고, 이 부분이 디스코스의 설정과 관리를 복잡하게 만드는 영역이었으며, 야후 그룹이나 메일링 리스트와 같은 레거시 시스템과 비교해도 마찬가지라고 동의합니다.
우리는 이미 trust levels, everyone, 그리고 moderator/admin과 같이 특별한 처리를 받는 특수 그룹들을 가지고 있습니다. 그렇다면 카테고리 보안 설정에서 직접, 백그라운드에서 카테고리 접근 권한에만 사용되는 특수 그룹의 생성을 허용할 수 있을까요? 다음과 같은 방식입니다:
foo 카테고리에 대해:
foo_see, foo_reply, foo_create 그룹을 생성하고 해당 사용자를 추가foo_moderator 그룹을 생성하도록 허용foo 접근 권한 그룹은 /groups 페이지에서 보일 수 없으며, 작성기에서 @를 입력할 때 추천되지 않음foo 접근 권한 그룹은 특정 foo 카테고리와 연결되어 있으며, 다른 카테고리에 접근하는 데 사용할 수 없음foo의 하위 카테고리는 현재와 같이 혼란스러운 순환 오류 처리 대신 foo에 자동으로 접근 권한을 부여받을 수 있음이 방식에서 좋은 점은 카테고리를 볼 때 해당 카테고리에 접근 권한이 있는 모든 사람의 이름과 누가 보기, 답변, 생성 권한을 가지고 있는지 확인하는 UI를 노출할 수 있다는 것입니다. 저는 이것이 항상 결여된 부분이라고 느껴왔습니다. 현재 우리가 제공하는 유일한 프로그램matic한 정보는 카테고리가 보안 설정되어 있음을 나타내는 
아이콘일 뿐이며, 누가 접근 권한을 가지고 있는지 알 수 없습니다.
이 기능을 카테고리 설정 내에 두면, 카테고리와 그룹 생성 방식을 단순화할 수 있습니다. 이는 더 많은 사용자가 보안 카테고리를 생성하고 관리할 수 있는 문을 열어줍니다. 사이트 관리자들과 함께 카테고리 접근 권한을 관리할 수 있는 사람들을 위한 foo_owner 그룹도 있을 수 있습니다.
이것이 어떻게 보일지 확실하지 않으며, 이러한 변경에 대한 의향이 없을 수도 있지만, 우리는 브레인스토밍과 새로운 아이디어를 항상 환영합니다. 특히 목업(mockup)이 포함된 아이디어라면 더 좋습니다!
흥미롭네요. 다만 여전히 다소 복잡하게 느껴집니다 (기존 구조 위에 구축되어 있어 어쩔 수 없는 부분일 수도 있겠지만요).
그룹은 이미 부풀려져 있는 느낌입니다 (어떤 멤버가 어떤 그룹에 속해 있는지 항상 헷갈리거든요 - 네, 네이밍이 나쁜 건 압니다). 따라서 foo 타입 접근 방식은 주로 카테고리에서 확인되도록 하는 것이 좋을 것 같습니다. 적어도 기본적으로 그룹에서 해당 항목을 표시할지 여부에 대한 체크박스는 제공해야겠죠.
아쉬운 점은 Discourse가 제가 전혀 익숙하지 않은 도구로 만들어져 있다는 것입니다. 직접 데이터베이스에 접근하는 유틸리티를 만들기는 할 수 있겠지만, 다른 분들은 이미 스크립트로 훨씬 더 잘하고 계시기에… 글쎄요, 은퇴할 때쯤이면 가능할지도 모르겠네요 
.