Granulare gruppenbasierte Berechtigungen für anonyme und angemeldete Benutzer

Nachrichten und Veranstaltungen Ankündigungen
44

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

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

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.

Ja, klar, ich mache das alles nur um der „Änderung willen“ :+1: 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.“}

3 „Gefällt mir“
45

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! :+1:)

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 (:+1:), 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?

46

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:

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.

2 „Gefällt mir“