Schlechtes Verhalten, ein altes Thema hochzuholen, aber ich konnte kein neueres finden. Bitte erleuchten Sie mich.
Ich benutze das Forum heutzutage für viele seltsame Dinge.
Ich neige dazu, schreibgeschützte Kategorien für private Zwecke mit nur einem Zugriffsberechtigten zu erstellen (um es für alle einfach zu halten, die kein tatsächliches Konto erstellen möchten). Manchmal erstellt ein Benutzer ein Konto und erhält auch Schreibrechte. Außer dass ich anscheinend eine Gruppe category_xyz_see und category_xyz_write haben muss, um dies zu ermöglichen. Nun, das ist nur Arbeit.
Irgendwie scheint es seltsam, dass man Gruppen nur unter Sicherheit hinzufügen kann, aber ein Benutzer, der schließlich ein weiteres Objekt ist, kann nicht hinzugefügt werden.
Habe den Einladungsansatz nicht ausprobiert (hinter SSO, auch wenn er wahrscheinlich inzwischen behoben ist).
Außer dass ich diese speziell erstellten Benutzer verwende, die auf private Kategorien zugreifen können.
Der Grund dafür ist, dass die Leute heutzutage wirklich keine weitere Kontoerstellung „irgendwo“ wünschen. Für kurzlebige Informationen, Monate oder maximal zwei Jahre, verwende ich entweder ein Login mit Lesezugriff auf die öffentlichen Bereiche der Website oder ein bestimmtes Login, das Zugriff auf eine geschlossene Kategorie hat.
Dieser Ansatz scheint mehr Leser anzuziehen und einige konvertieren zu tatsächlichen Benutzern, wenn sie andere interessante Dinge auf der Website finden.
Ein erforderliches Login hält die Website sauber.
Ich schreibe dies nur als Anwendungsfall, wie jemand sein Discourse nutzt, nichts weiter. Als Entwickler interessiere ich mich normalerweise, wenn Leute Dinge tun, die ich mir nicht vorgestellt habe.
Da dies jedoch durch Hinzufügen einer weiteren Gruppe mit anderen Rechten gelöst werden kann, zu der Sie die benötigten Benutzer hinzufügen, ist es keine große Sache.
Wenn man darüber nachdenkt, ist die Definition eines PM ein Thema mit individueller Zugriffskontrolle. Sie erscheinen an verschiedenen Stellen in der Benutzeroberfläche, aber beides zu haben, wäre super verwirrend.
Ich halte das für eine interessante Idee. Wir haben im Allgemeinen versucht, Parität für Gruppen bei den Benutzern zu erreichen. Dies ist das erste Mal, dass ich das Gegenteil sehe.
Für sehr kleine Websites oder für Kategorien, die nur für eine Handvoll von Personen bestimmt sind, könnte es sehr nützlich und zweckmäßig sein, Benutzernamen neben Gruppennamen in die Sicherheitsfelder der Kategorie eintragen zu können. Aber offensichtlich wird es unhandlich, sobald man anfängt, viele Benutzernamen hinzuzufügen.
Ich denke, ich stimme Stephen hier nicht zu, zumindest aus der Sicht eines Programmierers. Ob Sie einen Benutzer oder eine Gruppe haben, ist irrelevant, beides sind Objekte. Soweit ich das sehe, überlappen sie sich und können Überschneidungen haben.
Wäre es in der Benutzeroberfläche verwirrend, vielleicht. Vielleicht auch nicht. Wir müssen die Überschneidung nicht anzeigen und ein Benutzer, der auch in einer Gruppe existiert, ist irrelevant (das System muss das herausfinden).
Ich bin auch auf die Einschränkung gestoßen, dass eine Unterkategorie Zugriff auf der übergeordneten Kategorieebene haben muss. Das ist irgendwie sinnvoll. Ich schätze, ich könnte das Ganze umdrehen, aber in diesem speziellen Fall würde es sich rückwärts anfühlen.
Ich werde den tatsächlichen Anwendungsfall noch einmal zeigen, das erklärt das Warum viel einfacher. Mir fehlen vielleicht die richtigen englischen Wörter, aber ich denke, die Leute werden den Kern verstehen.
Eine Person ist gestorben und viele Leute sind im Nachlass.
Ein schreibgeschützter Benutzer wurde für einfacheren Zugriff erstellt (dieser Benutzer wurde zu einer „Sehen“-Gruppe hinzugefügt).
Einige Leute, die bereits auf der Website sind, wurden ebenfalls zur Gruppe hinzugefügt (damit sie sich nicht abmelden und das Konto wechseln müssen).
Die oberste Kategorie enthält allgemeine Informationen, Beerdigung usw.
Eine Unterkategorie enthält Geldinformationen (die noch unklar sind, daher noch nicht für alle freigegeben, bis alle Probleme gelöst sind). Wenn Sie hier einen vertrauenswürdigen Mann hinzufügen (der außerhalb des Nachlasses sein könnte), bedeutet das nicht, dass er Zugriff auf die oberste Kategorie benötigt (oder haben sollte).
Ich bin sicher, dass ich mit ein wenig Nachdenken eine gute Lösung dafür finden könnte. Aber im Grunde würde die Möglichkeit, einzelne Benutzer auf jeder Ebene hinzuzufügen, dies schöner (und logischer) lösen.
Außerdem ist all dies fast mit zusätzlichen Gruppen erreichbar, also ist es wahrscheinlich die Mühe nicht wert.
Die Konzepte von Gruppen und Kategorien sind in Discourse fest verankert und berühren viele Dinge, daher bin ich mir nicht sicher, ob es die Bereitschaft gibt, dies zu ändern. Es wäre eine massive Änderung.
Dennoch stimme ich zu, dass dies immer ein Bereich war, der Discourse kompliziert erscheinen lässt, wenn es um Einrichtung und Verwaltung geht, selbst im Vergleich zu Altsystemen wie Yahoo Groups oder Mailinglisten.
Wir haben bereits einige spezielle Gruppen, die eine spezielle Behandlung erhalten, z. B. trust levels, everyone und moderator/admin. Vielleicht könnten wir auch die Erstellung spezieller Gruppen zulassen, die nur für den Zugriff auf Kategorien im Hintergrund verwendet werden, direkt aus den Sicherheitseinstellungen der Kategorie? Etwas wie:
Für Kategorie foo:
Bereitstellung einer Benutzeroberfläche zur Auswahl von Benutzern und zur Gewährung von Zugriff zum Anzeigen, Antworten und Erstellen
Wenn Benutzer ausgewählt werden, Erstellung von Gruppen foo_see, foo_reply, foo_create und Hinzufügen von Benutzern zu diesen
Bereitstellung einer Benutzeroberfläche zum Entfernen von Benutzern und Ändern ihres Zugriffs zum Anzeigen, Antworten und Erstellen
Wenn die Moderation von Kategorien aktiviert ist, können auch Benutzer als Kategorie-Moderator angegeben und eine Gruppe foo_moderator dafür erstellt werden.
foo-Zugriffsgruppen sind nicht auf der Seite /groups sichtbar oder werden im Komponisten mit @ vorgeschlagen
foo-Zugriffsgruppen sind an eine bestimmte foo-Kategorie gebunden und können nicht für den Zugriff auf andere Kategorien verwendet werden
Unterkategorien von foo können automatisch Zugriff auf foo erhalten, anstatt der aktuellen zirkulären Fehlerbehandlung, die verwirrend ist.
Was mir daran gefällt, ist, dass wir auch eine Benutzeroberfläche beim Betrachten einer Kategorie bereitstellen könnten, um die Namen aller Personen anzuzeigen, die Zugriff auf die Kategorie haben, und welche Personen Lese-, Antwort- und Erstellungszugriff haben. Ich habe immer das Gefühl, dass dies eine Lücke war. Derzeit ist die einzige programmatische Information, die wir bereitstellen, das , das anzeigt, dass eine Kategorie gesichert ist – wir wissen nicht, wer Zugriff hat.
Indem wir diese Funktionalität innerhalb der Kategorieeinstellungen platzieren, vereinfachen wir auch die Erstellung von Kategorien und Gruppen. Dies eröffnet die Möglichkeit, dass mehr Benutzer sichere Kategorien erstellen und verwalten können. Es könnte sogar eine foo_owner-Gruppe für Personen geben, die zusammen mit Website-Administratoren den Zugriff auf die Kategorie verwalten dürfen.
Ich bin mir nicht sicher, wie das aussehen könnte und ob es auch die Bereitschaft für eine solche Änderung gibt, aber wir freuen uns immer über Brainstorming und neue Ideen, vorzugsweise mit Mockups!
Interessant. Fühlt sich aber immer noch etwas umständlich an (vielleicht weil es auf dem aufbaut, was existiert, und somit ein Muss ist).
Gruppen fühlen sich bereits aufgebläht an (man verliert immer den Überblick, wer zu was gehört – ja, schlechte Benennung, ich weiß). Ein Foo-Ansatz sollte also vielleicht hauptsächlich von der Kategorie aus sichtbar sein. Zumindest eine Checkbox, ob diese standardmäßig in Gruppen angezeigt werden sollen.
Schade, dass Discourse mit Werkzeugen erstellt wurde, mit denen ich überhaupt nicht vertraut bin. Im besten Fall könnte ich Dienstprogramme erstellen, die direkt auf die Datenbank zugreifen. Was andere Leute sowieso mit ihren Skripten viel besser machen. Na ja, vielleicht, wenn ich in Rente gehe :).