Unabhängig davon wurde ich mehrmals gefragt, ob es in Zukunft die Möglichkeit gibt, den in Private topics permitted groups angegebenen Gruppen einen UI-Schalter zu geben, damit sie die gefilterte Ansicht selbst sehen können.
1 „Gefällt mir“
Dieses Problem wurde im letzten Commit behoben.
Um die Dinge (relativ) einfach und performant zu halten, werden Links von privaten Topics jetzt niemals einen Backlink generieren.
Danke für die Meldung, Stephen!
3 „Gefällt mir“
2 Beiträge wurden in ein bestehendes Thema zusammengeführt: Umbenennen von „privaten Themen“ in „persönliche Nachrichtenthemen“
Kurzzeitgedächtnisverlust. Das habe ich schon früher gesehen.
Ich habe mich jedoch gefragt, ob diese Art der Filterung von Themen aus allen Themenlisten Leistungsprobleme verursachen wird?
Ich habe bisher keine Beschwerden gehört. Das Plugin wurde mit Blick auf die Leistung entwickelt.
3 „Gefällt mir“
Wenn ein Beitrag in einem privaten Thema als gelöst markiert wird, erscheint dieser Beitrag im Tab “Gelöst” des Profils des Beitragsbesitzers und ist für alle sichtbar.
2 „Gefällt mir“
Vielen Dank für die Meldung. Wir werden uns so schnell wie möglich darum kümmern.
3 „Gefällt mir“
Das von @SubStrider gemeldete Problem wurde behoben. Bitte aktualisieren Sie auf Version 1.5.12 des Plugins.
Vielen Dank nochmals für die Meldung, @SubStrider 
5 „Gefällt mir“
Ich bin auf etwas gestoßen, das ich als Bug bezeichnen würde. Es ist vielleicht kein traditionelles Problem im Code, vielleicht eher ein Usability-Bug im Design. Dennoch hat es einige Probleme verursacht, die ich in Zukunft vermeiden möchte. Folgender Kontext:
Discourse-Instanz mit dreistelliger Nutzerzahl, die als Ersatz für eine Mailingliste verwendet wird. Etwa 40 Kategorien (= Mailinglisten) mit einer entsprechenden Gruppe für die Mitgliederverwaltung. Einige der Kategorien verwenden das Private Topics Plugin, um eine Mailingliste zu simulieren, in die Nicht-Mitglieder (aber Mitglieder anderer Listen) schreiben können. Soweit so gut.
Das Problem:
Heute schrieb der Admin-Benutzer einen Beitrag in einigen der Listen, um sich bei den Listenmitgliedern nach einigen Einstellungen zu erkundigen. Alles in Ordnung für „normale“/geschlossene Kategorien, bei denen nur die Mitglieder der entsprechenden Gruppe die Nachricht erhielten. Bei den Kategorien, die das Private Topics Plugin verwenden, funktionierte es nicht gut. Dort erhielten alle Hunderte von Benutzern, unabhängig davon, ob sie Mitglieder der jeweiligen Kategorie/Gruppe waren oder nicht, eine E-Mail mit der Nachricht. Dort erhielten alle Hunderte von Benutzern, die alle Mitglieder der Kategorie waren, da die Kategorieberechtigungen an 
everyone vergeben wurden[1], aber unabhängig davon, ob sie Mitglieder der spezifischen Gruppe waren, die in den Kategorie-Plugin-Einstellungen für sichtbare Rechte definiert war oder nicht, eine E-Mail mit der Nachricht. Wie später erkannt wurde, verwendete die Einstellung des Website-Plugins Private topics permitted groups immer noch die Standardgruppe Admin.
(Übrigens hatten wir dieses Problem schon einmal, bei dem ein Benutzer, der Admin war und zusätzlich seinen „normalen“ Account hatte, ein internes Dokument (versehentlich über die mit dem Admin-Benutzer verknüpfte E-Mail-Adresse und nicht über den normalen Benutzer) an eine Kategorie mit dem Private Topics Plugin gesendet hat, was zu Informationslecks führte. Damals habe ich die Zusammenhänge zu diesem Plugin nicht erkannt, erst heute wurde mir klar, was damals passiert war)
Erwartetes Verhalten:
Ich kann die Begründung für die Designentscheidung nachvollziehen, dass Beiträge/E-Mails von Admins immer sichtbar/per E-Mail versendet werden. Aber in diesem Fall war die Absicht, nur die Mitglieder der Kategorie/Gruppe zu informieren. Dass einige hundert E-Mails an alle in dieser Discourse-Instanz gesendet wurden, war für mich sehr intransparent (und unangenehm).
Mögliche Lösung:
Ich wünsche mir eine Verbesserung dieser Situation. Da Mailin ebenfalls verfügbar ist, wird ein einfacher Bestätigungsdialog nicht funktionieren. Vielleicht könnte dies eine globale Einstellung im Plugin oder pro Kategorie, die das Plugin verwendet, sein, um Admin-Beiträge entweder für alle sichtbar zu behandeln oder nur für Kategorie-/Gruppenmitglieder sichtbar zu machen? Das würde zumindest das Bewusstsein bei der Einrichtung einer neuen Kategorie schärfen.
was nicht verwendet werden sollte, sondern
trust_level_0verwendet werden sollte, siehe OP ↩︎
Können Sie mir bitte eine PN mit allen Informationen senden, die Ihnen einfallen und die relevant sind, einschließlich:
-
die Versionen von Discourse und dem Plugin
-
die Plugin-Einstellungen
-
andere Plugins, die Sie installiert haben
-
die Sicherheitseinstellungen der Kategorie und die kategoriespezifischen Plugin-Einstellungen für eine betroffene Kategorie
-
die Benachrichtigungseinstellungen
-
ist der E-Mail-Listenmodus aktiviert?
-
ob die Benutzer, die versehentlich die E-Mail-Benachrichtigung erhalten haben, das Thema auch sehen können, wenn sie die Kategorie besuchen
-
alles andere, was uns bei der Reproduktion helfen könnte
Danke für deine schnelle Antwort!
Erledigt. Und die Fragen haben mir geholfen, die Ursache zu finden (Website-Einstellungen: Plugin-Einstellungen: Private Themen erlaubte Gruppen). Also, code-mäßig funktioniert es wie vorgesehen, meiner Meinung nach ein UX-Problem, das von einigen Verbesserungen profitieren würde. 
Eine der kontraintuitiven Erkenntnisse war, dass private Themen nicht korrekt funktionieren, wenn der Zugriff für „jeder“ gewährt wird. Dies wird in der OP erwähnt, aber um ehrlich zu sein, bin ich auch schon mehr als einmal darauf hereingefallen. Ich habe eine Warnung in den Einstellungen hinzugefügt, die angezeigt wird, wenn private Themen in einer Kategorie aktiviert sind, auf die „jeder“ zugreifen kann.
3 „Gefällt mir“
Vielen Dank nochmals an @RGJ, dass er sich die Zeit genommen hat, das Problem mit mir zu debuggen und zu durchdenken, und mir geholfen hat, meinen Konfigurationsfehler bei der Verwendung der everyone-Gruppe zu erkennen. Da in meiner Installation nur angemeldete Benutzer Zugriff auf Discourse-Inhalte haben, habe ich anfangs den Unterschied zwischen everyone und trust_level_0 nicht verstanden – aber jetzt weiß ich, dass Discourse diese recht unterschiedlich behandelt. Es gibt also kein Problem mit dem Plugin, und umso dankbarer bin ich für die hinzugefügte Warnung, da ich befürchte, ich wäre früher oder später wieder in diese Falle getappt… 
2 „Gefällt mir“