Es gibt in unserer Codebasis historisch bedingt eine verwirrende Pseudogruppe namens @everyone, die für Folgendes verwendet werden kann:
- Site-Einstellungen vom Typ
group_list - Kategorienberechtigungen
- Tag-Gruppen
In einigen Fällen verstehen die Leute unter @everyone „alle anonymen und alle angemeldeten Benutzer“, während andere nur „alle angemeldeten Benutzer“ darunter verstehen. In der Realität bedeutet es für Site-Einstellungen in den meisten Fällen jedoch nur „alle angemeldeten Benutzer".
Zusätzlich verwässert wird die Situation durch die Tatsache, dass diese @everyone-Gruppe bei Site-Einstellungen verwendet werden kann, bei denen es keinen Sinn ergibt, dass „alle anonymen und angemeldeten Benutzer“ Zugriff auf die Funktion haben, wie zum Beispiel pm_tags_allowed_for_groups.
Dies ist auch aus Sicht des Feature-Flaggings und der Entwicklererfahrung verwirrend, da wir bei einigen bevorstehenden Änderungen oder anderen Einstellungen diese möglicherweise wirklich für „alle anonymen und angemeldeten Benutzer“ aktivieren möchten.
Lösung
Wir führen zwei separate automatische Pseudogruppen ein:
anonymous (ID 4)– Steht für anonyme Benutzer, die Ihre Seite ohne Konto besuchenlogged_in_users (ID 5)– Steht für alle angemeldeten Benutzer Ihrer Seite, ähnlich wie die automatische Gruppetrust_level_0, aber spezifischer
Diese wurden bereits eingeführt, treten jedoch erst in Kraft, wenn die bevorstehende Änderung granular_anonymous_and_logged_in_groups_permissions auf Ihrer Seite aktiviert ist.
Wenn die bevorstehende Änderung aktiviert ist, wird jede Einstellung, bei der everyone als ausgewählte Gruppe festgelegt ist, automatisch in die ID logged_in_users übersetzt. Dadurch werden beim Umschalten der bevorstehenden Änderung keine Daten in der Tabelle der Site-Einstellungen verändert. Sobald die bevorstehende Änderung dauerhaft wird, führen wir eine Datenmigration für alle Gruppeneinstellungen durch, um diese Änderung vorzunehmen.
Darüber hinaus haben wir anonymous für mehrere Site-Einstellungen, bei denen es keinen Sinn ergibt, als disallowed_group markiert, zum Beispiel personal_message_enabled_groups.
Was ist mit Tag- und Kategorienberechtigungen?
Diese Berechtigungen bleiben unverändert, da ihr Konzept von „jeder“ sich in einigen Punkten unterscheidet und nicht auf der zugrunde liegenden automatischen Gruppe basiert.