@dax 2020년에도 포스터의 그룹에 속한 사용자만 해당 토픽의 게시물을 볼 수 있도록 제한할 수 없다는 말이 맞나요?
우리는 온라인 학습 시스템에 Discourse를 사용하고 싶습니다. 약 7개의 토픽으로 구성된 한 세트를 만들고, 서로 다른 코호트(그룹)의 사용자가 이 토픽들을 순서대로 진행하면서 자기 그룹 내부의 게시물만 볼 수 있도록 하려고 합니다. 매번 새로운 코호트가 생길 때마다 동일한 토픽을 반복해서 생성하는 것보다는 하나의 토픽 세트를 사용하는 것이 훨씬 좋습니다.
그 사이에 이 기능을 가능하게 해주는 새로운 기능이 추가되었을 수도 있나요? 의견 주시면 감사하겠습니다.
@sam 빠른 답변 감사합니다! 우리의 정확한 시나리오를 기준으로 설명을 명확히 해 보겠습니다:
4개 과정을 제공하기 위해 카테고리 4개를 설정해 두었습니다.
각 카테고리(과정)에는 “수업(Lesson)” 하나당 하나의 주제(topic)로 구성된 약 5~10개의 주제가 있습니다. 여기에 “기술적 질문”, “자기소개” 등 몇 가지 추가 주제도 포함되어 있습니다. 각 수업이 진행될 때마다 학생들은 해당 주제에 기여하도록 요청받습니다.
많은 수의 학생 코호트(cohort)가 이 과정들을 거칠 예정이며, 주제 내 게시물을 해당 코호트 "그룹"으로 제한하고자 합니다. 이렇게 하면 카테고리과 주제는 그대로 유지하면서, 사용자의 속성을 수정하여 다른 그룹에 할당하는 방식으로 관리할 수 있습니다. 이 그룹은 API를 통해 생성(?)하고, 학생들을 동적으로 할당(?)할 수 있을 것입니다.
따라서 제가 "특정 주제 안에서, 특정 그룹에 속한 사용자만 볼 수 있는 메시지를 생성할 수 있습니까?"라는 상위 질문을 주목하게 된 배경이 바로 이 것입니다.
@waffleslop 훌륭합니다. 감사합니다. 새로운 코호트가 생길 때마다 매번 해당 하위 카테고리를 수동으로 생성하나요? (아니면 API를 통해 생성하나요?)
매 코호트마다 하위 카테고리에 동일한 5~10개의 새 주제를 설정해야 하므로 이를 피하고 싶었습니다. 또한 한 번의 과정 진행 중에 여러 코호트가 동시에 진행될 수도 있으므로, 명명 규칙에 대해 창의적으로 생각해 봐야 할 것 같습니다. 그러니 말씀하신 예시를 바탕으로 하면 … 2020-05-cohort-A Course Conversations
… 혹은 아직 살펴보지 못했지만 하위-하위-하위 카테고리(sub-sub-subcategories)를 만들 수 있는 방법이 있을지도 모르겠습니다.
새로운 cohort가 들어오면 해당 cohort를 위한 새 카테고리를 생성하세요. 학생들이 아이콘을 클릭한 다음 "새 주제"를 클릭하여 해당 cohort 카테고리 내에서 해당 과제에 대한 새 주제를 생성하도록 하세요. 저는 각 과제에 과제 태그를 붙여 사람들이 과제를 수행했는지, 언제 수행했는지 추적하기 쉽게 했습니다(또한 제가 그들의 주제에 "좋아요"를 누르면 배지가 수여되도록 배지를 만들었고, 심지어 이 작업을 모두 자동으로 수행하고 CSV를 생성하여 사용하고 싶지 않던 대학 LMS에 업로드하는 스크립트까지 만들었습니다).
이것이 코스 아래에 군집을 그룹화하기 위해 하위 카테고리를 사용하고, 그런 다음 그룹 권한을 사용하여 해당 하위 카테고리로 제한하는 것이 불가능하다는 뜻이라고 이해하는 것이 맞나요? @waffleslop 님은 귀하의 접근 방식에서 하위 카테고리로 제한할 수 있었나요? 아마도 제가 그 UI 메시지를 잘못 읽고 있는 것일 수도 있습니다.
하위 카테고리를 특정 그룹으로 제한할 수 없다면, @pfaffman 님의 접근 방식(설명해 주셔서 감사합니다)인 각 군집마다 새 카테고리를 만드는 것이 유일한 옵션일 것 같습니다.
우리 코스의 주제 10개 정도는 상당히 고정되어 있고, 구체적인 이름과 번호 등이 지정되어 있으므로, 시스템에서 새 군집이 생성될 때마다 API를 통해 이를 생성할 계획입니다. 즉, LMS에서 새 군집을 생성할 때마다 API를 사용하여 다음을 수행할 것입니다:
해당 군집을 위해 Discourse에 새 카테고리를 생성합니다.
해당 카테고리에 접근할 수 있는 새 그룹을 Discourse에 생성합니다.
새 카테고리에 올바른 주제 10개 정도를 생성합니다.
LMS에서 학생이 군집에 추가될 때마다 Discourse의 올바른 그룹에 추가합니다 (나갈 경우 제거합니다).
학생이 주제 자체를 생성하도록 하는 대신 이 접근 방식을 시도해 보신 적이 있나요? 같은 과제를 위해 서로 다른 학생들이 약간 다른 이름의 주제를 생성하는 문제에 대해 궁금합니다.
이 문제의 한 측면에 대해 "읽기 전용 카테고리"를 사용하라는 귀하의 제안이 명확하지 않습니다.
위에서 설명한 접근 방식을 따르는 모든 분, 즉 각 과정 '코호트’마다 하위 카테고리를 사용하고 각 하위 카테고리에서 토론 주제를 반복하는 경우, “중복된 주제 제목 허용” 설정을 반드시 활성화하세요. 그렇지 않으면 Discourse가 각 하위 카테고리에서 동일한 주제를 반복하는 것을 허용하지 않습니다.
현재 베타 단계이지만 Discourse 통합은 잘 진행되고 있습니다. 저희 사이트에서 로그인 강제를 위해 SSO 통합을 사용하고 있습니다. 잘 작동하고 있지만, 몇 가지 사항을 확인했습니다.
Discourse는 사용자명에 “@” 기호가 포함된 것을 허용하지 않습니다… “@” 앞부분만 잘라서 사용자명을 저장합니다… 나중에 해당 사용자명을 인자로 Discourse API를 호출할 때 문제가 될 수 있습니다. Discourse에서는 someone@example.com과 같은 사용자명을 인식하지 못합니다. Discourse에서 해당 사용자의 사용자명은 "someone"으로 저장되어 있기 때문입니다… 이 문제를 피하기 위한 쉬운 방법은 자체 사용자명에서 “@” 기호를 사용하지 않는 것입니다!
사용자가 자체 사이트에 가입할 때, SSO 사용자를 동기화하기 위해 Discourse API를 명시적으로 호출해야 합니다. 이는 사용자가 Discourse 사이트를 처음 방문하기 전에 해당 사용자와 관련된 작업(예: Discourse 그룹에 추가)을 수행하려는 경우에 필요합니다(처음 방문 시 SSO가 자동으로 동기화됩니다). 저는 Django 기반 사이트를 사용하고 있으며, pydiscourse 라이브러리를 사용하여 sync_sso 메서드로 이를 쉽게 처리하고 있습니다 (pydiscourse · PyPI)
네, 일부 과정은 만료됩니다. 이 경우 서버가 Discourse API를 호출하여 해당 과정의 일반 그룹과 해당 과정 내 코호트에 전담된 그룹에서 사용자를 제거합니다.
저는 Django 사이트에서 이러한 “과정” 그룹과 각 과정 내의 다양한 “코호트” 그룹을 추적하는 테이블을 생성했습니다. 따라서 학생을 추가/제거할 때 이 정보를 사용합니다: