Granulare gruppenbasierte Berechtigungen für anonyme und angemeldete Benutzer

[martin (Martin Brennan)]

@merefield

Also waren einige Leute verwirrt, weil „everyone“ nur angemeldete Benutzer bedeutet?

Wer?!

„Everyone“ bedeutet doch bestimmt „jeder“ – das ist doch sehr klar.

Das war es aber nicht, und wir haben es intern und extern immer wieder gesehen, und zwar überall im Code.

@merefield

Also muss eine Kategorie, die vollständig öffentlich ist, jetzt mindestens zwei Gruppen haben statt einer – „angemeldet“ und „anonym“? Das ist albern und keine Verbesserung?

Ich bin noch nicht bei den Kategorien angekommen, hier hat sich nichts geändert.

@merefield

Indem man nur TL0 zu „angemeldete Benutzer“ ändert, bricht man jetzt die Konsistenz, dass jedes Sicherheitsniveau eine Schwelle ist. TL1 ist ebenfalls eine Schwelle und keine echte „einzelne Gruppe“. Bedeutet das, dass wir eine Gruppe namens „angemeldete Benutzer, die mindestens auf Vertrauensstufe 1 sind“ brauchen?!

Die Leute haben TL0 überwiegend verwendet, um „alle angemeldeten Benutzer“ zu meinen, weil wir keine bessere Möglichkeit hatten, dies darzustellen. Die Gruppe logged_in_users ist zumindest völlig klar, was sie umfasst, und es steht dir absolut nichts im Weg, weiterhin TL0/TL1 usw. zu verwenden. Die einzige Gruppe, die entfernt wird, ist everyone.

@merefield

Änderung um der Änderung willen

Ja, klar, ich mache das alles nur um der „Änderung willen“ Bitte überlege dir einen Moment deine Wortwahl. Wir haben es hier nicht in uns, völlig unnötige Dinge ohne Grund zu tun. Diese Arbeit läuft seit Monaten und die Richtung ändert sich nicht.“}

[merefield (Robert)]

Okay, vielleicht verstehe ich diese Änderung falsch?

Wenn der Vorschlag lautet, Folgendes einzuführen:

• anon
• angemeldet

als automatische Gruppen,

dann klingt das gut und ist selbsterklärend.

(Tatsächlich gefällt mir das sogar ziemlich gut! )

Falls der Vorschlag jedoch lautet, schließlich Folgendes zu entfernen:

• alle

dann ergibt das für mich keinen Sinn, denn „alle“ ist Teil eines Satzes automatischer Gruppen, die Zugriffsstufen darstellen und unter anderem Folgendes umfassen:

• trust_level_0
• trust_leve_1

usw.

Sie alle stellen Zugriffsstufen dar, einschließlich „alle“.

Die Gruppe „alle“ ist auch bekannt als „trust_level_none“.

Es ist eine knappe Art, öffentlichen Zugriff auszudrücken.

Ich verstehe, dass ihr sie für die Kategorieberechtigungen vorerst nicht entfernen wollt (), aber ich würde persönlich gerne ein Bekenntnis sehen, diese automatische Gruppe beizubehalten, da sie für mich zumindest Sinn ergibt.

Und warum sollte sie nicht auch woanders verwendet werden dürfen, genau wie jede andere automatische Trust-Level-Gruppe?

Sonst müsstest du an jeder Stelle, an der du „öffentlichen Zugriff“ ausdrücken musst, zwei Gruppen hinzufügen, was eine sinnlose Komplexität darstellt?

Warum die Mühe machen, Logik hinzuzufügen, um „alle“ auszublenden?

Vielleicht wäre ein alternativer Ansatz, den Namen „alle“ zu überdenken, falls es einen besseren Namen gibt, aber seine Bedeutung, Funktionalität und Verfügbarkeit über die gesamte Plattform hinweg beizubehalten – und dann ist doch alle (hust) zufrieden?

[martin (Martin Brennan)]

Ich denke, der Unterschied hier liegt zwischen einer bequemen Möglichkeit, „Öffentlich zugreifbar“ auszuwählen, und dem Beibehalten der bestehenden everyone-Gruppe. Ich bin einverstanden, dass es umständlicher ist, jedes Mal zwei Gruppen auswählen zu müssen, wenn man öffentlichen Zugriff benötigt, und wir können das über die Benutzeroberfläche verbessern.

Zum Beispiel könnten wir eine „Öffentlich“-Schnellwahl in der Gruppenauswahl hinzufügen, die beide Gruppen anonymous_users und logged_in_users in einem einzigen Schritt auswählt. Du würdest dann sehen, dass beide Gruppen ausgewählt sind, und könntest eine davon entfernen. Das bietet dir die von dir beschriebene Bequemlichkeit, während die zugrunde liegenden Berechtigungen explizit bleiben. Wir würden diese Schnellwahl nur dort anbieten, wo beide Gruppen erlaubt sind.

Das Problem mit dem Beibehalten der bestehenden everyone-Gruppe ist, dass sie nicht durchgehend „öffentlichen Zugriff“ bedeutet hat. Für die Sichtbarkeit von Kategorien tut sie das, aber für die meisten gruppenbasierten Seiteneinstellungen hat sie faktisch „alle angemeldeten Benutzer“ bedeutet. Es gibt auch Themes und Plugins, die sie unterschiedlich interpretieren, wie die obige Diskussion gezeigt hat.

Wir können also nicht einfach beibehalten und sagen, dass sie überall anonyme Benutzer einschließt, ohne potenziell Zugriffe zu gewähren, die es vorher nicht gab. Das Beibehalten des bestehenden Verhaltens würde die Inkonsistenz wahren, und ein Umbenennen würde das Problem auch nicht lösen.

Eine konsistent definierte universelle Gruppe wäre möglich, aber sie würde immer noch die Migration und das Audit erfordern, die wir gerade durchführen. Sie müsste auch überall dort verboten werden, wo kein anonymes Zugreifen unterstützt wird, sonst wären wir wieder bei „everyone“, was an diesen Stellen „nur angemeldete Benutzer“ bedeutet. Es gibt eine Menge Einstellungen, bei denen ich anonymous_users als Wert für disallowed_groups hinzufügen musste, obwohl es das vorher nicht gab, und bei denen everyone zuvor erlaubt war. Zum Beispiel:

@martin

Das Wasser wird weiter trüb, weil diese @everyone-Gruppe auf Seiteneinstellungen verwendet werden kann, bei denen es keinen Sinn ergibt, dass „alle anonymen und angemeldeten Benutzer“ Zugriff auf die Funktion haben, wie z. B. pm_tags_allowed_for_groups.

Ich würde es vorziehen, diese Bequemlichkeit in der Benutzeroberfläche bereitzustellen, indem wir die beiden expliziten Gruppen darunter verwenden. Dann haben wir überall Konsistenz für Administratoren und Entwickler.

[merefield (Robert)]

@martin

Zum Beispiel könnten wir eine „Öffentlich“-Schnellwahl in der Gruppenauswahl hinzufügen, die mit einem einzigen Klick sowohl anonymous_users als auch logged_in_users auswählt. Du würdest dann beide Gruppen als ausgewählt sehen und könntest jeweils eine davon entfernen. Das bietet dir die von dir beschriebene Bequemlichkeit, während die zugrunde liegenden Berechtigungen explizit bleiben. Wir würden diese Schnellwahl nur dort anbieten, wo beide Gruppen erlaubt sind.

Alle sind sehr explizit – das wirkt auf mich wie unnötige Unhandlichkeit – aber ich schätze die erhaltene Bequemlichkeit.

@martin

aber bei den meisten gruppenbasierten Site-Einstellungen hat es faktisch „alle angemeldeten Benutzer“ bedeutet. Es gibt auch Themes und Plugins, die es anders interpretieren, wie die obige Diskussion gezeigt hat.

Meiner Meinung nach liegt genau dort das Problem (war/is) und nicht beim ursprünglichen „everyone“-Kategoriekonzept.

Die „everyone“-Gruppe und ihre Verwendung im grundlegenden Kategoriensystem existiert seit … 2013?

work in progress, add fidelity to category group permissions (full, create posts, readonly)

Wenn sich das Einstellungssystem davon entfernt und diesen Vertrag gebrochen hat, ist das dann nicht ein Problem mit der Arbeit am Einstellungssystem?

Meiner Meinung nach wäre es schön gewesen, wenn es ein RFC gegeben hätte, damit die Community vorab Ideen dazu beisteuern konnte, bevor es anscheinend direkt in die Umsetzung geht.

Entschuldigung, falls ich etwas übersehen habe …

[martin (Martin Brennan)]

Ja, ich stimme dir zu, dass die Inkonsistenz in den Seiteneinstellungen Teil des Problems ist. Aber das zu beheßen bedeutet nicht unbedingt, dass die bestehende everyone-Gruppe für Seiteneinstellungen weiterhin verwendet werden muss.

Ich glaube, das Argument aus dem Jahr 2013 sagt uns nicht viel darüber aus, als nur, wie lange everyone für Kategorieberechtigungen existiert hat. An Discourse hat sich seit 2013 vieles geändert; zum Beispiel basierten viele Seiteneinstellungen früher auf dem Vertrauenslevel, während sie jetzt gruppenbasiert sind. Niemand bestreitet, dass das in diesem Kontext sinnvoll ist, und die Kategorieberechtigungen werden durch diese Arbeit nicht verändert (zumindest vorerst). Das Alter der Gruppe begründet nicht, dass sie im Rest von Discourse eine konsistente Bedeutung hat, oder dass wir sie auf unbestimmte Zeit beibehalten sollten.

Selbst wenn wir uns einig wären, dass jede Abweichung von der ursprünglichen Bedeutung ein Fehler war, müssen wir trotzdem damit umgehen, wie diese Einstellungen auf bestehenden Seiten tatsächlich funktionieren. Wir können ihre Interpretation nicht sicher dahingehend ändern, dass anonyme Benutzer einbezogen werden, nur weil dies besser zum ursprünglichen Kategorienverhalten passen würde. Wie ich oben erklärt habe, würde das Beibehalten einer universellen Gruppe mit konsistenter Bedeutung immer noch eine Prüfung und Migration dieser Verwendungsfälle erfordern. Es ist ein alternatives Design, aber es vermeidet nicht den schwierigen Teil dieser Arbeit.

Zum Punkt mit dem RFC: Ein gemeinschaftliches RFC, bevor Änderungen wie diese vorgenommen werden, wäre langsam und unzumutbar, auch wenn Feedback willkommen ist – genau dafür ist das kommende Änderungssystem da. Dieses Thema hat bereits zu mehreren Verbesserungen aufgrund der Beispiele von Moin geführt, und ich habe die Fälle mit Themen/Komponenten anerkannt, die ich anfangs übersehen hatte, und sie ebenfalls behoben.

Ich bin gerne bereit, konkrete Probleme mit der Änderung weiter zu bearbeiten, aber ich werde trotzdem mit den zwei expliziten Gruppen fortfahren. Öffentlichen Zugriff in der UI bequem auszuwählen, scheint ein vernünftiger Weg zu sein, um das zusätzliche Klicken zu beheben, aber ich denke nicht, dass es gerade jetzt notwendig ist, dies umzusetzen.

Wie auch immer, ich habe immer noch eine Menge Arbeit in The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions für diesbezügliches nachverfolgt, also wird es noch eine Weile dauern, ebenso wie jegliche Änderungen im Zusammenhang mit dem Kategoriesystem, das everyone vorerst beibehält. Kategorien werden wahrscheinlich zu einem System wechseln, das wir ACLs nennen, welches Kanban bereits verwendet: