Im Grunde hoffen wir, Gruppen einzurichten, um Beendigungsberechtigungen innerhalb eines Themas zu verwalten, aber wir möchten, dass jeder Benutzer und nicht registrierte Gäste lesen können, was gepostet wird.
Gibt es eine Möglichkeit, dies zu ermöglichen?
Kategorie -\u003e Sicherheit
Ich verstehe den Sinn von Antworten einschränken jedoch nicht.
Ich verstehe, dass Sie das für eine Kategorie tun können, aber wir hoffen, keine komplett neue Kategorie erstellen zu müssen, da all diese Themen bereits ordentlich in Kategorien und Unterkategorien sortiert sind.
Wir hoffen wirklich auf die Möglichkeit, Antworten (und tatsächlich auch Likes) pro Thema einschränken zu können.
Soweit ich weiß, geht das nicht ohne Weiteres. Aber ich würde mich gerne irren.
Vielleicht möchten Sie diese Themen archivieren.
Ich bin mir nicht sicher, wie das es Benutzern einer bestimmten Gruppe immer noch erlaubt, dort zu posten…
Ach, Entschuldigung @orangeandblack5, ich habe deine ursprüngliche Frage nicht berücksichtigt, sondern nur auf diesen Teil geantwortet:
Lass uns von vorne anfangen…
In Discourse legen wir Gruppenberechtigungen auf Kategorieebene fest, nicht auf Postebene, daher glaube ich nicht, dass es eine Möglichkeit gibt, das zu tun, wonach du fragst.
Ich bin neugierig: Warum möchtest du nicht, dass jeder, der die Themen lesen kann, sie auch liken kann? Ich dachte an Archivierung, weil du sie vielleicht “einfrieren” wolltest, aber es klingt, als ob du möchtest, dass einige Leute die Like-Möglichkeit haben und andere nicht. Ich liebe es zu hören, wie Leute Discourse in ihren Communities nutzen! 
Für uns ist das Posten weitaus wichtiger als das Liken, aber im Allgemeinen nutzen wir Discourse, um verschiedene Arten von Online-Spielen und Diskussionen zu veranstalten, an denen Leute teilnehmen müssen, um sich anzumelden. Es verstößt gegen die Regeln, in einem Spiel zu posten, das man nicht tatsächlich spielt, aber wir haben keine Software-Durchsetzung dafür, und so werden neue Benutzer manchmal verwirrt und stören versehentlich Dinge, obwohl sie sich stattdessen für ein bevorstehendes Thema anmelden sollten.
Eine Möglichkeit, jedem zu erlauben, alle Themen zu lesen, aber Personen, die sich nicht für ein bestimmtes Thema angemeldet haben, daran zu hindern, darin zu posten, wäre großartig!
Ich denke auch, dass der einzige Weg, dies ohne benutzerdefinierten Code zu erreichen, darin besteht, für jedes Spiel oder jede Diskussion, die Sie einschränken möchten, eine eigene Unterkategorie hinzuzufügen. Das klingt umständlich, aber da Sie jedes Mal eine eigene Gruppe einrichten müssen, ist es eigentlich nicht viel mehr manueller Aufwand. Auf jeden Fall wird die Benutzererfahrung mit einer solchen Einrichtung sauber sein:
Themen von Spiel-A sind also für alle sichtbar, aber jeder, der kein Mitglied der Spiel-A-Gruppe ist und das Thema öffnet, kann nicht antworten.
Wenn Sie eine sehr saubere Benutzeroberfläche wünschen und dies mit Ihrer Architektur übereinstimmt, könnten Sie die relevanten Unterkategorien-Badges sogar mit CSS aus der Benutzeroberfläche ausblenden. Die Unterkategorien dienen also rein den Zugriffsrechten und nicht der Navigation.
Das Problem dabei ist, dass wir bereits Unterkategorien zur Sortierung verwenden.
Wir werden es zumindest in Betracht ziehen, aber es ist wirklich nicht ideal, da wir eine ganze Ebene der Sortierung/Organisation entfernen müssten und das die Navigation auf der Website erheblich erschweren könnte, insbesondere für neue Benutzer.
Ich vermute, dass Sie Tags verwenden sollten, um einige dieser Organisationen vorzunehmen. Siehe It’s Time We Talked About Tags.
Es wird keine einfache Möglichkeit geben, Berechtigungen pro Thema zu erhalten.
Ich frage mich, ob es eine Möglichkeit gibt, Seitenveröffentlichung für PMs bereitzustellen?
Das glaube ich nicht. Aber Sie könnten sie in einer Kategorie veröffentlichen, in die Leute schreiben können, und sie dann aus der Liste nehmen.
Dies ist getrennt vom Anwendungsfall des OP, aber ich verwalte ein Forum mit einer anonymen Kategorie, in der Benutzer über berufliche Angelegenheiten schreiben können, ohne ihre Benutzernamen für alle anderen preiszugeben (obwohl sie wissen, dass die Administratoren herausfinden können, wer was gepostet hat, wenn sich jemand danebenbenimmt). Es wäre großartig, Likes auch nur für anonyme Benutzer einschränken zu können.
Ich habe die gleiche Situation: Wir nutzen Discourse als Teil unseres benutzerdefinierten LMS und möchten manchmal den Zugriff auf ein Thema in einem Kurs auf bestimmte Kohorten im Kurs beschränken.
Der einzige Weg, dies zu tun (wie oben erklärt), ist, eine Kategorie für den Kurs zu erstellen und dann eine Unterkategorie für jede Kohorte, die den Zugriff einschränken muss… dann jedes Thema in jede Unterkategorie kopieren, was eine ziemliche Plackerei ist, einschließlich der Notwendigkeit, Modelle auf unserer Seite zu haben, die diese Einrichtung widerspiegeln, und Code, um die Dinge synchron zu halten.
Es wäre sooo viel besser, wenn wir Beiträge in jedem Thema auf Gruppen beschränken könnten.
:denkend:
Muss jede Person die Antworten aller anderen Kohorten erreichen?
Wenn ich das einrichten würde, würde ich die Materialien in eine Kategorie legen, die keine Antworten zulässt, nur als Referenzmaterial.
Dann würde ich eine Gruppen-PM senden, die auf das Material verlinkt, und die Diskussion dort führen.
Auf diese Weise organisieren Sie einfach Kohorten in Gruppen und können die Materialien leicht wiederverwenden. ^ _ ^
So funktionieren PMs! 
Aber nicht für öffentliche Themen.
@maiki Wooooah. Das wusste ich nicht. Danke fürs Teilen!!!
Mit der aktuellen Strategie ist es jedoch eher ein “Set and Forget”. Wenn ein Kurs erstellt wird, können wir das Thema und die Unterkategorie für die STANDARD-Kohorte erstellen und dann die gewünschten Themen einfügen. Wenn eine neue Kohorte hinzugefügt wird, erstellen wir eine neue Gruppe und Unterkategorie und kopieren die Themen.
Dann können wir es vergessen und die Aktivitätsbenachrichtigungen nur über den Callback abwickeln.
Wäre mit dem von Ihnen beschriebenen Ansatz mehr manuelle Arbeit verbunden? “Senden einer Gruppen-PM” klingt nach einer Aktivität, die während der Lebensdauer eines Kurses stattfindet. Wenn sich ein neuer Student in einen bestehenden Kurs einschreibt und einer bestimmten Kohorte zugeordnet wird, können wir ihn zur richtigen Gruppe in Discourse hinzufügen, und er hat dann Zugriff auf die bestehende Unterkategorie (für diese Kohorte) und die Kopie aller Themen, die sie enthält. Würde er in diesem Fall automatisch zu einer bestehenden “Gruppen-PM” hinzugefügt werden, sodass kein Unterschied im Workflow besteht?
Würde die Benutzeroberfläche gleich aussehen? Derzeit haben wir nur das Thema und dann alle Beiträge (für eine bestimmte Kohorte, falls erforderlich) darunter, gemäß der “üblichen” Discourse-Benutzeroberfläche.
Ich muss sagen, ich hasse es, jedes Mal Unterkategorien und Kopien aller Themen erstellen zu müssen, wenn auf unserer Seite eine neue Kohorte erstellt wird, und das verwalten zu müssen, daher klingt diese direkte PM faszinierend. Aber ich habe diese Bedenken, dass die Verwendung einer “privaten Nachricht”, um alles zu tun, was eine Kategorie + Themen leisten können, irgendwo etwas vermissen lässt.
Ich kann mir nicht wirklich vorstellen, wie das für die Benutzer aussieht.
Ich weiß nur, dass ich oft auf Themen verlinke oder Vorlagen verwende, um Inhalte in PMs wiederzuverwenden, wenn ich mit wiederverwendbaren Inhalten arbeite.
Wenn Sie ein wenig darauf eingehen möchten, was Sie tun, mit Beispielthemen und Antworten von Studenten, damit wir die Kohorten-Erfahrung sehen können, würde ich gerne darüber nachdenken, wie wir dies mit PMs erreichen können.
Was ich getan habe, war, eine schreibgeschützte Kategorie mit den Aufgaben zu haben und die Schüler als “verknüpftes Thema antworten” antworten zu lassen, wenn sie die Aufgabe “beantworteten”, indem sie in der Klassenkategorie posteten. Ich bin mir nicht sicher, wie einfach es heutzutage ist, “als verknüpftes Thema antworten” bei einem schreibgeschützten Beitrag zu finden.
Danke @pfaffman und @maiki für eure Gedanken. Wir haben die Themen so integriert, dass wir über die API die neuesten Beiträge zu einem Thema abrufen und diese direkt auf der relevanten Kursseite in unserem LMS anzeigen:
Wenn Sie dann auf „An der Diskussion teilnehmen“ klicken, gelangen Sie zum Thema in der Kategorie für den Kurs und der Unterkategorie für Ihre Kohorte im Kurs, wodurch Sie auf Kommentare von Ihren Kohortenkollegen beschränkt werden:
Was ein wenig seltsam ist, ist, dass diese Architektur in die Benutzeroberfläche übergeht, wie in dieser Kopfzeile:
und die Navigation…
Dies zwingt den Studenten zu verstehen, warum es eine übergeordnete Kategorie und dann eine Unterkategorieebene für die „Kursthemen“ (das ist die für seine Kohorte) und eine weitere für die „Allgemeine Diskussion“ (das ist die für alle Kohorten in einem Kurs) gibt … und wenn er herumklickt, kann er sich ein wenig verirren.
Manchmal sind Kohorten eher ein administratives Gruppierungsmechanismus, der den Studenten nicht interessiert, was diese Kategorie/Unterkategorie-Sache etwas verwirrender machen kann. „Warum gibt es nicht einfach eine Kategorie für alle Themen im Kurs?“
Außerdem bedeutet dieses Setup, wie ich bereits erwähnt habe, dass wir alle Themen duplizieren müssen, wann immer eine Kohorte erstellt wird, diesen Teil löschen, wenn eine Kohorte gelöscht wird, oder jede Unterkategorie aktualisieren, wenn ein Thema erstellt/aktualisiert/gelöscht wird.
