Hallo.\n\nDa wir jetzt bestimmten Gruppen Zugriff auf Whispers gewähren können, sind wir dem Entfernen des Moderatorzugriffs für die meisten unserer internen Benutzer sehr nahe.\n\nNon-moderator access to whispers als wir begannen, den Zugriff zu entfernen, stellten wir fest, dass uns ein letztes Teil fehlte und wir die Änderung rückgängig machen mussten. Wir nutzen Zuweisungen (an Benutzer und Gruppen) in unserer Organisation intensiv.\n\nAll dies ist vor unserer Benutzergemeinschaft “verborgen”. Das funktioniert für uns wirklich gut, denn manchmal weisen wir Threads einer Gruppe zu, weil…\n\n- wir nur Feedback weitergeben (zur Information)\n- wir eine Aktion benötigen\n- wir nicht wissen, ob eine Aktion ergriffen werden muss (und die Gruppe dies herausfindet, sobald sie es sieht)\n\nInternen Benutzern wird vertraut, Threads anderen Gruppen in der Organisation zuzuweisen.\n\nWas wir feststellten, als wir begannen, den Moderatorzugriff zu widerrufen, ist, dass die Gruppensichtbarkeit und die Möglichkeit, Gruppen zuzuweisen, nur bis zu “nur Gruppenmitglieder, Moderatoren und Administratoren” erweitert werden können, bevor wir externen Benutzern die Möglichkeit geben müssten, Gruppen zu sehen und ihnen zuzuweisen.\n\nEs wäre großartig, wenn diese Berechtigungen auch auf Gruppenebene definiert werden könnten. Für uns ist dies das letzte fehlende Teil.\n\nWas uns antreibt:\n\nIch denke, es ist wichtig zu erwähnen, warum wir uns überhaupt auf diese Reise begeben.\n\nWir haben ca. 170 Moderatoren in unserer Instanz. Diese Benutzer benötigen keinen Zugriff auf die E-Mail-Adressen und IP-Adressen unserer Benutzer. Insbesondere da unser Unternehmen weiter wächst, fühlt es sich riskant an, diese Informationen jedem zur Verfügung zu stellen.
Nur am Rande der Hauptfunktionsanfrage, aber hilft die Admin-Einstellung moderators view emails bei diesem Problem?
Ehrlich gesagt, ich hatte keine Ahnung, dass diese Option existiert – und tatsächlich ist sie in unserer Instanz deaktiviert! Ich habe mich als ein anderer Moderator unserer Instanz ausgegeben und tatsächlich können diese keine E-Mail-Adressen einsehen.
Ich schwöre, ich hatte Zugriff, um E-Mails einzusehen, als ich „nur“ ein Moderator (kein Administrator) war – vielleicht hatten wir damals eine andere Einstellung (unsere Instanz hat in den letzten 8 Monaten eine ziemliche Reise hinter sich).
Vielen Dank, dass Sie darauf hingewiesen haben.
Das nimmt also definitiv etwas Dringlichkeit weg – und generell würde ich mir wünschen, dass die Plattform sich weiterhin in Richtung flexibler gruppenbasierter Berechtigungen bewegt und nicht hin zu diesen rigideren Optionen.
Entschuldigung, können Sie hier etwas näher erläutern?
Wir arbeiten auch bei Discourse an einem ähnlichen Problem. Tatsächlich habe ich keinen Admin-/Moderatorzugriff auf unsere Entwicklungsinstanz. Ich verstehe vollkommen die enormen Vorteile, die geringe Anzahl von Administratoren/Moderatoren beizubehalten.
Können Sie das Problem darlegen?
Beachten Sie, dass es einige Bausteine gibt, auf die Sie sich stützen können:
- Kategorie-Moderation: Sie können die Moderation über bestimmte Kategorien für bestimmte Gruppen definieren. Dies gibt Benutzern mit hohem Vertrauen mehr Flexibilität.
- Vertrauensstufensystem … bei TL4 (manuell) wird viel freigeschaltet
assign allowed on groups(Zuweisung für Gruppen erlaubt) Site-Einstellung (die die Zuweisung für bestimmte Gruppen freischaltet)
Gerne. Gerne erweitere ich.
Wir haben eine Reihe verschiedener Teams in unserem Unternehmen, die als Fachexperten (SMEs) für die jeweiligen Produktbereiche, für die sie verantwortlich sind, zu unserer Community beitragen. Für jedes Team wird eine Gruppe erstellt, und wenn die Expertise eines Teams zu einem Thema benötigt wird, wird das Thema dem Team zugewiesen (und normalerweise dann einem Einzelnen zugewiesen, der es von sich selbst abweist, wenn er alles beigetragen hat, was er kann).
Wir möchten unseren Benutzern nicht offenlegen, wie das alles funktioniert. Wir versuchen, die Erwartungen niedrig zu halten (es ist kostenloser Support, den wir unseren Open-Source-Benutzern anbieten), wir möchten nicht, dass Benutzer anfangen zu fragen: „Warum können Sie das nicht einfach dem _____ Team zuweisen??“ – tatsächlich möchten wir nicht, dass unsere Benutzer wissen, dass diese Gruppen überhaupt existieren.
Normalerweise bin ich für radikale Transparenz, aber das funktioniert für uns wirklich gut.
Und wir möchten, dass unsere internen Benutzer alle diese Gruppen, die ihnen zugewiesenen Themen sehen und die Möglichkeit haben, sie anderen Gruppen zuzuweisen.
Aber die Berechtigungen für die Gruppeninteraktion:
- Wer kann diese Gruppe sehen?
- Wer kann die Mitglieder dieser Gruppe sehen?
- Wer kann diese Gruppe @erwähnen?
- Wer kann diese Gruppe anschreiben?
- Wer kann diese Gruppe zuweisen?
Sind auf die folgenden Berechtigungen beschränkt
Das bedeutet, dass wir mindestens Moderatorzugriff gewähren müssen, wenn wir sicherstellen wollen, dass alle unsere internen Benutzer die Gruppen so sehen/mit ihnen interagieren können, wie wir es brauchen. Das ist nicht ideal.
Ich hoffe, das hilft, das Problem zu verdeutlichen. Lassen Sie mich wissen, wenn ich etwas weiter klären kann.
Ich verstehe, das ist in der Tat eine knifflige Situation. Ich stimme zu 100 % zu, dass wir diese Dropdown-Liste von:
zu:
Welche Gruppen sind erlaubt für X:
[my-group/owners group1 group2 etc... ]
Tatsächlich würde dies wahrscheinlich die Benutzeroberfläche und die interne Implementierung vereinfachen, die sich nicht mehr mit Enums usw. auseinandersetzen müsste.
Das Schwierigste an einem Port ist, dass „Gruppenbesitzer“ keine echte Gruppe ist, sodass wir eine Art neues Primitiv benötigen würden, um zu beschreiben, was es bedeutet. Gruppen-ID reicht nicht aus.
[quote=„Gruppenbesitzer“ ist keine echte Gruppe,]
Es wäre hilfreich, wenn es eine echte Gruppe wäre!
Meine Funktionsanfrage genau dafür:
Ehrlich gesagt, fällt es mir schwer, einen echten Anwendungsfall zu finden, bei dem Gruppenbesitzer nicht alles tun dürfen, nur weil sie Gruppenbesitzer sind.
In diesem Fall könnten Sie dieses Problem vielleicht ignorieren und Gruppenbesitzern “Gott-Rechte” gewähren. Die restlichen Berechtigungen werden dann an einzelne Gruppen delegiert.
Ich verstehe, aber ich mache mir große Sorgen über Änderungen, die bestehende Funktionalität beeinträchtigen. Durch die Unterstützung einer einfachen „Gruppenbesitzer“-Shadow-Gruppe können wir komplett auf eine neue Benutzeroberfläche umstellen, ohne bestehende Benutzer der Funktion zu beeinträchtigen.
Ich verstehe Ihre Perspektive dazu vollkommen!