Granulare gruppenbasierte Berechtigungen für anonyme und angemeldete Benutzer

Nachrichten und Veranstaltungen Ankündigungen
1

In unserem Codebase gibt es 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 wird @everyone von einigen als „alle anonymen und alle angemeldeten Benutzer“ interpretiert, während andere es nur als „alle angemeldeten Benutzer“ verstehen. In der Realität bedeutet es für Site-Einstellungen jedoch in den meisten Fällen nur „alle angemeldeten Benutzer“.

Verwirrend wird es zusätzlich dadurch, dass diese @everyone-Gruppe auch bei Site-Einstellungen verwendet werden kann, bei denen es keinen Sinn ergibt, dass „alle anonymen und angemeldeten Benutzer“ Zugriff auf die Funktion haben, wie beispielsweise pm_tags_allowed_for_groups.

Dies ist auch aus der Perspektive des Feature-Flaggings und der Entwicklererfahrung verwirrend, da wir für einige anstehende Änderungen oder andere Einstellungen möglicherweise wirklich möchten, dass sie für „alle anonymen und angemeldeten Benutzer“ aktiviert werden.

Lösung

Wir führen zwei separate automatische Pseudogruppen ein:

  • anonymous_users (ID 4) – Repräsentiert anonyme Benutzer, die Ihre Site ohne Konto besuchen
  • logged_in_users (ID 5) – Repräsentiert alle angemeldeten Benutzer Ihrer Site, ähnlich wie die automatische Gruppe trust_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 Site 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. Daher werden beim Umschalten der bevorstehenden Änderung keine Daten in der Tabelle der Site-Einstellungen geändert. Sobald die bevorstehende Änderung dauerhaft wird, führen wir eine Datenmigration für alle Gruppeneinstellungen durch, um diese Änderung vorzunehmen.

Zusätzlich haben wir anonymous_users für mehrere Site-Einstellungen, bei denen es keinen Sinn ergibt, als disallowed_group markiert, beispielsweise für personal_message_enabled_groups.

image
image1217×205 51.6 KB

Konflikte mit bestehenden Gruppennamen werden automatisch gelöst, indem die bestehenden Gruppen umbenannt und Erwähnungen von Gruppen in Beiträgen aktualisiert werden.

Was ist mit Tag- und Kategorienberechtigungen?

Diese Berechtigungen bleiben unverändert, da ihr Konzept von „everyone“ in einigen Punkten anders ist und nicht auf der zugrunde liegenden automatischen Gruppe basiert.

9 „Gefällt mir“
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

Warte… was? :flushed_face: Bedeutet das, dass alle Kategorien, die jetzt öffentlich (für alle) sind, zu geschlossenen Kategorien werden, die eine Anmeldung erfordern, sobald dies aktiviert ist?

4

Nein, denn:

[quote=“martin, Beitrag:1, Thema:402273”]

Was ist mit Berechtigungen für Tags und Kategorien?

Diese Berechtigungen bleiben unverändert, da ihr Konzept von „alle

1 „Gefällt mir“
5

Kann mir jemand helfen zu verstehen, wie ich meine Theme-Komponenten anpassen muss?

Ich habe versucht, die copy-post-Komponente als Beispiel zu verwenden, da ich mich erinnere, dass sie ebenfalls eine Gruppeneinstellung verwendet, die den Zugriff auf die Funktion gewährt. Und dass es ein Problem gab, weil die Pseudogruppe „everyone“ eine separate Prüfung erforderte, genau wie in meiner Komponente, denn der Vergleich der IDs der Gruppen, denen der Benutzer angehört, hilft nicht – diese IDs müssen separat geprüft werden. Deshalb habe ich eine kürzliche Änderung dort erwartet, denn wie ich verstehe, sind die neuen Gruppen ebenfalls Pseudogruppen und die ID müsste separat geprüft werden. Fehlt mir etwas, das erklärt, warum dies hier nicht notwendig ist?

Meine favorite filters-Komponente hat zwei Gruppeneinstellungen: eine, die Gruppen erlaubt, ihre eigenen Filter zu speichern, und eine, die Standardfilter anbietet.
Standardmäßig können nur Mitglieder der Gruppe trust_level_0 benutzerdefinierte Filter verwenden, da nur registrierte Benutzer Daten in einem benutzerdefinierten Benutzerfeld speichern können. Hier wäre es also sinnvoll, wenn ich anonymous_users nicht als Auswahl zulassen würde. Wie mache ich das in einer Theme-Komponente? Gibt es dafür bereits ein Beispiel?

Die Standardeinstellung für die Standardfilter ist „everyone“, da ich es hilfreich finde, dass sogar nicht registrierte Benutzer die Standardfilter sehen und verwenden können. Das Problem ist, dass everyone zu ‚logged_in_users‘ geändert wird, obwohl ich es explizit ausgewählt habe. Muss ich dafür eine eigene Migration erstellen, damit Admins, die derzeit everyone verwenden, in Zukunft weiterhin Filter für nicht registrierte Benutzer haben? Wann muss diese Migration stattfinden? Oder muss jeder Admin dies nach der Ausführung der Migration einzeln ändern?

Ist all das, worüber ich mir Sorgen mache, tatsächlich unnötig? Falls Anpassungen erforderlich sind, wirken weniger als vier Wochen angesichts der Anzahl der von der Community gepflegten Komponenten, die potenziell betroffen sein könnten, ziemlich kurz.
Zusätzlich zu „copy-post“ habe ich mir auch die unanswered filter component angesehen, aber auch dort konnte ich keine Änderungen finden. Es fühlt sich an, als würde ich etwas Wichtiges übersehen. Schließlich ist die Änderung seit fast einer Woche standardmäßig aktiviert. Deshalb gehe ich davon aus, dass offizielle Komponenten bereits aktualisiert worden wären, wenn Anpassungen notwendig wären.

1 „Gefällt mir“
6

3 Beiträge wurden in ein bestehendes Thema zusammengeführt: Modernisierung des Foundation-Themas

7

Bei diesen Komponenten ist currentUser?.groups ohnehin nicht zuverlässig, da sie nur sichtbare Gruppen für den Benutzer enthält, während die Gruppen, die sich auf Berechtigungen auswirken, hier möglicherweise nicht serialisiert sind:

Im Kern und in Plugins umgehen wir dieses Problem, indem wir im Current-User-Serializer so etwas wie Folgendes tun:

Offensichtlich steht dies jedoch Theme-Komponenten und Themes sowie deren Einstellungen nicht zur Verfügung.

Hmm, bin mir nicht sicher, muss mir das noch überlegen. Wenn du wirklich everyone meintest, müsste dies sowohl zu logged_in_users ALS AUCH zu anonymous_users geändert werden. Das war das Hauptproblem mit everyone, wie im ursprünglichen Beitrag (OP) erwähnt – einige verstanden darunter nur angemeldete Benutzer, andere angemeldete plus anonyme Benutzer, und es war stark situationsabhängig.

Ich habe die Interpretation „nur angemeldete Benutzer

3 „Gefällt mir“
Introducing Upcoming Changes, a system to manage new features and changes to existing functionality in your community
9

Kurzes Update: Ich habe eine Idee, wie wir das handhaben können, und wir führen gerade interne Diskussionen dazu. Hoffentlich dauert das nicht zu lange :crossed_fingers:

1 „Gefällt mir“
10

Das bin genau ich :upside_down_face:. Um also eine Kategorie nur für registrierte Benutzer zu erstellen, habe ich die Zugriffsberechtigung auf TL0 festgelegt und verlaufe mich auf die automatische Benutzergruppe TL0, um angemeldete Benutzer von Gästen zu unterscheiden.

Ich frage mich, ob es eine Tabelle gibt, um die Bedeutung dieses Begriffs in verschiedenen Kontexten zu unterscheiden. Solche Unterschiede sind sowohl verwirrend als auch beunruhigend – denn als die Leute diese Einstellung ursprünglich wählten, wussten sie wahrscheinlich nicht, was sie tatsächlich bedeutet. Daher würden sie die entsprechenden Einstellungen überprüfen wollen. Derzeit kann ich nur jeden Ort, an dem Gruppen eingestellt sind, einzeln überprüfen und bestätigen, was es früher bedeutete, indem ich sehe, wem es nach der Aktivierung der Granular-Gruppen-Funktion geändert wurde – was sich anfühlt, als würde ich im Dunkeln tasten.

2 „Gefällt mir“
11

Das ist eine gute Idee… Vielleicht kann ich mit KI etwas zaubern, um in all den Orten zu suchen, an denen gruppenbasierte Einstellungen verwendet werden, und auszugeben, ob es überhaupt möglich ist, dass anonymous auf diese Dinge zugreifen kann.

Es gibt eine Reihe von Einstellungen, die bereits die Auswahl der Gruppe anonymous_users nicht zulassen, also sind das wahrscheinlich ein guter Ausgangspunkt… werde hier mit den Ergebnissen zurückmelden.

Ich arbeite gerade an PRs dafür:

Es wird bald darauf weitere PRs und Änderungen an der Dokumentation geben.

3 „Gefällt mir“
12

@Noble_Fish, dies ist die KI-generierte Liste der gruppenbasierten Einstellungen, wofür die Einstellung dient und wie sich anonyme/angemeldete Benutzer auf diese Einstellung auswirken. Sei dir bewusst, dass ich zwar ziemlich sicher bin, dass dies korrekt ist, aber wie bei allem, was von einer KI generiert wird, ist es gut, die Fakten selbst noch einmal zu überprüfen.

Ich denke, die interessanteste Spalte ist “everyone schloss vor der Änderung auch anonymous_users ein?”, wenn hier “Ja” steht, bedeutet das, dass everyone vor dieser anstehenden Änderung sowohl angemeldete als auch anonyme Benutzer umfasste.

Wie du sehen kannst, gibt es nur wenige davon, also sind das die einzigen, bei denen ein Administrator anonymous_users explizit in den Site-Einstellungen hinzufügen müsste:

  • hidden_post_visible_groups - Ich muss diese tatsächlich ändern, um anonymous_users zu erlauben, der Code ist für diese anstehende Änderung noch nicht ganz richtig.
  • lazy_load_categories_groups - Ich muss diese auch reparieren, sie führt eine redundante everyone-Prüfung durch, die bereits in user.in_any_groups? durchgeführt wird.
  • styleguide_allowed_groups - Dies funktioniert so wie es ist, aber ich werde es auch ein wenig anpassen.

Wenn diese anstehende Änderung endgültig wird, werden die Gruppen logged_in_users und anonymous_users ausschließlich verwendet und everyone wird gelöscht.

Einstellung Beschreibung logged_in_users zutreffend? anonymous_users zutreffend? everyone schloss vor der Änderung auch anonymous_users ein? Code-Feststellung
whispers_allowed_groups Erlaube private Kommunikation innerhalb von Themen für Mitglieder der angegebenen Gruppen. Nein Nein Nein everyone, logged_in_users und anonymous_users sind nicht erlaubt; zur Laufzeit wird auch konkrete Gruppenmitgliedschaft erwartet.
hidden_post_visible_groups Erlaube Mitgliedern dieser Gruppen, versteckte Beiträge anzuzeigen. Staff-Mitglieder können immer versteckte Beiträge anzeigen. Ja Nein Ja Prüft everyone, bevor anonyme Benutzer abgelehnt werden; verwendet andernfalls in_any_groups?.
about_page_hidden_groups Zeige Mitglieder bestimmter Gruppen auf der /about-Seite nicht an. Nein Nein Nein Verwendet group_users; Pseudogruppen haben keine Mitgliederzeilen.
about_page_extra_groups Gruppen, die auf der About-Seite unter den Moderatoren angezeigt werden. Nein Nein Nein Lädt konkrete Gruppen und Mitglieder zur Anzeige.
anonymous_posting_allowed_groups Gruppen, die das anonyme Posten aktivieren dürfen. Ja Nein Nein Gate für angemeldete Benutzer über in_any_groups?; anonymous_users ist nicht erlaubt.
personal_message_enabled_groups Erlaube Benutzern in diesen Gruppen, persönliche Nachrichten zu erstellen. Ja Nein Nein Gate für angemeldete Benutzer über in_any_groups?; anonymous_users ist nicht erlaubt.
shared_drafts_allowed_groups Erlaube Benutzern in diesen Gruppen, gemeinsame Entwürfe anzusehen und zu bearbeiten. Ja Nein Nein Guardian/Gate für angemeldete Benutzer; anonymous_users ist nicht erlaubt.
here_mention_allowed_groups Gruppen, die @here erwähnen dürfen. Ja Nein Nein Erfordert authentifizierten Benutzer; anonymous_users ist nicht erlaubt.
approve_unless_allowed_groups Beiträge von Benutzern, die nicht in diesen Gruppen sind, müssen genehmigt werden. Ja Nein Nein Benutzer-Gate über in_any_groups?; anonymous_users ist nicht erlaubt.
approve_new_topics_unless_allowed_groups Neue Themen von Benutzern, die nicht in diesen Gruppen sind, müssen genehmigt werden. Ja Nein Nein Benutzer-Gate über in_any_groups?; anonymous_users ist nicht erlaubt.
skip_review_media_groups Benutzer außerhalb dieser Gruppen haben Beiträge mit eingebetteten Medien, die zur Überprüfung eingereicht werden. Ja Nein Nein Benutzer-Gate über in_any_groups?; anonymous_users ist nicht erlaubt.
content_localization_allowed_groups Gruppen, die lokalisierte Inhalte aktualisieren dürfen. Ja Nein Nein Guardian/Benutzer-Gate; anonymous_users ist nicht erlaubt.
email_in_allowed_groups Gruppen, die neue Themen per E-Mail posten dürfen. Ja Nein Nein E-Mail-Absender-Benutzer-Gate; anonymous_users ist nicht erlaubt.
view_raw_email_allowed_groups Gruppen, die rohen eingehenden E-Mail-Inhalt anzeigen können. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
uploaded_avatars_allowed_groups Gib Gruppen an, die benutzerdefinierte Profilbilder hochladen dürfen. Ja Nein Nein Current/Target-Benutzer-Gate; anonymous_users ist nicht erlaubt.
create_topic_allowed_groups Gruppen, die neue Themen erstellen dürfen. Ja Nein Nein Erfordert Benutzer und verwendet in_any_groups?; anonymous_users ist nicht erlaubt.
topic_timers_allowed_groups Gruppen, die Topic-Timer setzen dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
edit_wiki_post_allowed_groups Gruppen, die Beiträge bearbeiten dürfen, die als Wiki markiert sind. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
edit_post_allowed_groups Gruppen, die Beiträge bearbeiten dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
self_wiki_allowed_groups Erlaube Benutzern in diesen Gruppen, ihre eigenen Beiträge als Wiki zu markieren. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
send_email_messages_allowed_groups Gruppen, die persönliche Nachrichten per E-Mail senden dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
flag_post_allowed_groups Gruppen, die Beiträge melden dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
post_links_allowed_groups Gruppen, die Links in Beiträgen einfügen dürfen. Ja Nein Nein Erfordert authentifizierten Benutzer; anonymous_users ist nicht erlaubt.
embedded_media_post_allowed_groups Benutzer in diesen Gruppen dürfen Medienbeiträge in einem Beitrag einbetten. Ja Nein Nein Acting-Benutzer-Gate; anonymous_users ist nicht erlaubt.
profile_background_allowed_groups Gruppen, die einen Profil-Hintergrund hochladen dürfen. Ja Nein Nein Benutzer-Gate; anonymous_users ist nicht erlaubt.
user_card_background_allowed_groups Gruppen, die einen User-Card-Hintergrund hochladen dürfen. Ja Nein Nein Benutzer-Gate; anonymous_users ist nicht erlaubt.
invite_allowed_groups Gruppen, die Benutzer einladen dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
ignore_allowed_groups Gruppen, die andere Benutzer ignorieren dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
delete_all_posts_and_topics_allowed_groups Gruppen, die Beiträge und Themen löschen dürfen, die von anderen Benutzern erstellt wurden, und gelöschte Inhalte anzeigen. Ja Nein Nein Guardian/Current-Benutzer-Gate; anonymous_users ist nicht erlaubt.
edit_all_topic_groups Erlaube Benutzern in dieser Gruppe, die Titel, Tags und Kategorien von Themen anderer Benutzer zu bearbeiten. Ja Nein Nein Raw-Split dann in_any_groups?; anonymous_users ist nicht erlaubt.
edit_all_post_groups Erlaube Benutzern in dieser Gruppe, Beiträge anderer Benutzer zu bearbeiten. Ja Nein Nein Benutzer-Gate über in_any_groups?; anonymous_users ist nicht erlaubt.
change_post_ownership_allowed_groups Erlaube Benutzern in diesen Gruppen, die Eigentümerschaft von Beiträgen zu ändern. Ja Nein Nein Current-Benutzer-Gate; anonymous_users ist nicht erlaubt.
cross_origin_opener_unsafe_none_groups Versteckte COOP-Override-Gruppen; zugeordnete Benutzer erhalten Cross-Origin-Opener-Policy: unsafe-none. Ja Nein Nein Erfordert current_user.present?; anonyme Auswahl hat keine Laufzeitwirkung.
user_api_key_allowed_groups Gruppenmitgliedschaft erforderlich für die Generierung von Benutzer-API-Schlüsseln. Ja Nein Nein Current-Benutzer-Gate; anonymous_users ist nicht erlaubt.
create_tag_allowed_groups Gruppen, die Tags erstellen dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
edit_tags_allowed_groups Gruppen, die Tags, Tag-Beschreibungen und Tag-Synonyme bearbeiten dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
tag_topic_allowed_groups Gruppen, die Themen mit Tags versehen dürfen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
pm_tags_allowed_for_groups Erlaube Mitgliedern der eingeschlossenen Gruppen, jede persönliche Nachricht zu taggen. Ja Nein Nein Guardian-Benutzer-Gate; anonymous_users ist nicht erlaubt.
lazy_load_categories_groups Lade Kategorieinformationen nur für Benutzer dieser Gruppen lazy. Ja Ja Ja Explizite everyone-Prüfung plus Guardian in_any_groups?; anonymous_users ist sinnvoll.
chat_allowed_groups Benutzer in diesen Gruppen können chatten, außer anonyme Benutzer, die Chat nur anzeigen können, wenn sie zu dieser Einstellung hinzugefügt werden. Ja Ja Nein Angemeldeter Chat verwendet in_any_groups?; anonymer öffentlicher Chat prüft explizit anonymous_users.
direct_message_enabled_groups Erlaube Benutzern innerhalb dieser Gruppen, persönliche Chats von Benutzer zu Benutzer zu erstellen. Ja Nein Nein Guardian-Gate für angemeldeten Chat; kein sinnvoller anonymer DM-Pfad.
chat_pinning_messages_allowed_groups Benutzer in diesen Gruppen dürfen Chat-Nachrichten anheften. Ja Nein Nein Erfordert Chat-Zugriff/Current-Benutzer; kein anonymer Pin-Pfad.
chat_message_flag_allowed_groups Benutzer in diesen Gruppen dürfen Chat-Nachrichten melden. Ja Nein Nein Benutzer-Gate; anonymer Pfad wird durch umgebende Chat-Berechtigungen blockiert.
no_ads_for_groups Zeige Benutzern in diesen Gruppen keine Werbung. Ja Nein Nein Nur zum current_user-Serializer hinzugefügt; keine anonymer Current-User-Payload.
adsense_exclude_groups Werbung wird Mitgliedern dieser Gruppen nicht angezeigt. Ja Nein Nein Current-User-Werbe-Flagge über in_any_groups?; keine anonymer Current-User-Payload.
dfp_exclude_groups Werbung wird Mitgliedern dieser Gruppen nicht angezeigt. Ja Nein Nein Current-User-Werbe-Flagge über in_any_groups?.
amazon_exclude_groups Werbung wird Mitgliedern dieser Gruppen nicht angezeigt. Ja Nein Nein Current-User-Werbe-Flagge über in_any_groups?.
carbonads_exclude_groups Werbung wird Mitgliedern dieser Gruppen nicht angezeigt. Ja Nein Nein Current-User-Werbe-Flagge über in_any_groups?.
adbutler_exclude_groups Werbung wird Mitgliedern dieser Gruppen nicht angezeigt. Ja Nein Nein Current-User-Werbe-Flagge über in_any_groups?.
composer_ai_helper_allowed_groups Benutzer in diesen Gruppen sehen die KI-Helfer-Schaltfläche im Composer. Ja Nein Nein Gate für angemeldeten KI-Helfer über in_any_groups?.
post_ai_helper_allowed_groups Benutzergruppen, die auf KI-Helfer-Funktionen in Beiträgen zugreifen dürfen. Ja Nein Nein Gate für angemeldeten KI-Helfer über in_any_groups?.
ai_pm_summarization_allowed_groups Gruppen, die Zusammenfassungen in PMs erstellen und anzeigen dürfen. Nein Nein Nein Verwendet rohe user.group_ids, sodass Pseudogruppen nicht übereinstimmen.
ai_bot_debugging_allowed_groups Erlaube diesen Gruppen, eine Debug-Schaltfläche zu sehen, die die rohe AI-Anfrage und -Antwort anzeigt. Ja Nein Nein Gibt explizit false für Anonyme zurück und verwendet dann in_any_groups?.
ai_bot_allowed_groups Wenn der GPT-Bot Zugriff auf die PM hat, antwortet er Mitgliedern dieser Gruppen. Ja Nein Nein Primäre Gates verwenden in_any_groups?; ein Playground-Pfad verwendet rohe group_ids.
ai_bot_public_sharing_allowed_groups Erlaube diesen Gruppen, KI-Personal-Messages über einen eindeutigen Link mit der Öffentlichkeit zu teilen. Ja Nein Nein Gibt explizit false für Anonyme zurück und verwendet dann in_any_groups?.
assign_allowed_on_groups Benutzer in diesen Gruppen dürfen Themen zuweisen. Nein Nein Nein Verwendet rohe user.group_ids/GroupUser; Pseudogruppen haben keine Zeilen.
discourse_post_event_allowed_on_groups Gruppen, die Events erstellen dürfen. Nein Nein Nein Raw groups.where(id: ...); everyone ist special-cased, aber logged_in_users nicht.
discourse_kanban_manage_board_allowed_groups Gruppen, die Kanban-Boards erstellen und konfigurieren dürfen. Ja Nein Nein Guardian verwendet in_any_groups?, aber Write-Controller erfordern Login.
create_policy_allowed_groups Gruppenmitgliedschaft erforderlich für das Hinzufügen von Richtlinien zu Beiträgen. Ja Nein Nein Post/Benutzer-Gate über in_any_groups?.
flag_posts_voting_comments_allowed_groups Gruppen, die einen Post-Voting-Kommentar melden dürfen. Ja Nein Nein Benutzer-Gate über in_any_groups?.
allow_solved_in_groups Erlaube das Markieren von Lösungen in Gruppen-Nachrichten für diese Gruppen. Kein Benutzer-Gate Kein Benutzer-Gate Kein Benutzer-Gate Stimmt mit PM topic.allowed_groups überein, nicht mit Current-User-Mitgliedschaft.
accept_all_solutions_allowed_groups Gruppen, die Lösungen in jedem Thema akzeptieren dürfen. Ja Nein Nein Authenticated/Current-Benutzer-Gate über in_any_groups?.
discourse_templates_groups_allowed_private_templates Gruppen, die private Templates verwenden dürfen. Nein Nein Nein Raw GroupUser.exists?; nur everyone ist special-cased.
poll_create_allowed_groups Die Gruppen, die Umfragen erstellen dürfen. Ja Nein Nein Acting/Current-Benutzer-Gate über in_any_groups?.
styleguide_allowed_groups Beschränkt die Sichtbarkeit des Styleguides auf Mitglieder der angegebenen Gruppen. Ja Ja Ja Controller behandelt explizit anonymous_users; er erlaubte auch Anonyme über everyone vor der Änderung.
2 „Gefällt mir“
13

Hole diese Anpassungen in einen neuen PR aus:

2 „Gefällt mir“
14

@moin Dieser PR DEV: Add resolve_group_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub wurde jetzt gemerged und ich füge die Dokumentation in DEV: Docs for theme setting resolve_group_membership - Pull Request #41537 - discourse/discourse - GitHub hinzu. Ich habe discourse-copy-post mit DEV: Use resolve_group_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub behoben und gehe jetzt unsere anderen offiziellen Plugins durch, um zu sehen, ob andere dieselbe Behandlung benötigen (z. B. hast du bereits auf GitHub - discourse/discourse-unanswered-filter · GitHub hingewiesen).

Für dein eigenes Filter Favorites kannst du das copy-post-Beispiel sehen, das ich gemacht habe, aber im Grunde musst du resolve_group_membership: true sowohl zu default_favorite_filters_groups als auch zu custom_favorite_filters_allowed_groups hinzufügen, dann werden sie als Boolesche Werte basierend auf den Gruppenmitgliedschaften des Benutzers auf settings als settings.user_in_default_favorite_filters_groups und settings.user_in_custom_favorite_filters_allowed_groups verfügbar sein, und du musst nicht mehr manuell die Gruppen-IDs der Benutzer im Frontend überprüfen.

Ich würde den Standardwert von default_favorite_filters_groups in deinem Theme-Component auf 4|5 ändern, was angemeldete und anonyme Benutzer bedeutet, anstatt 0 (everyone), der bald entfernt wird.

Ich werde einen Hinweis machen, eine Datenbankmigration für Theme-Einstellungen auszuführen, wenn ich die everyone-Gruppe entferne. Ich muss auch eine für Site-Einstellungen machen. Dies wird passieren, wenn die kommende Änderung in den nächsten Wochen endgültig wird (abhängig davon, ob andere Probleme auftreten und wie schnell ich andere Themes/Components durchgehe, die resolve_group_membership hinzugefügt bekommen müssen).

Nein, das ist im Moment nicht möglich, wie es für Site-Einstellungen der Fall ist… Ich denke, es ist nicht notwendig, das jetzt hinzuzufügen. Du kannst dies einfach in der Beschreibung der Einstellung erwähnen und im Frontend mit currentUser schützen. Vielleicht werde ich das in Zukunft hinzufügen, wenn der Bedarf größer ist.

3 „Gefällt mir“
15

Funktioniert das auch für den Typ groups in den Objekteinstellungen?

16

Nein, muss das denn? Das war mir nicht bewusst, ich weiß nicht, ob das für Berechtigungen verwendet wird oder nicht.

17

Ich denke, es wird beispielsweise in Discourse Group Sidebar Menus verwendet, damit Administratoren konfigurieren können, welche Gruppen jede Seitenleisten-Sektion sehen dürfen, und es wird in Notification Banners verwendet, um die Sichtbarkeit jedes Banners zu konfigurieren.

Ich ging davon aus, dass du es auch in deiner Ads-Komponente verwenden würdest. Aber es scheint, dass diese stattdessen auf einer Liste von Gruppennamen basiert.

Ich bevorzuge die Gruppeneinstellungen vom Typ „Group“, da sie dem Administrator ermöglichen, Gruppen über ein Dropdown-Menü einfach auszuwählen, während sie auf Gruppen-IDs basieren, die sich im Vergleich zu Namen seltener ändern. Und ich finde es verwirrend, wenn die Gruppenliste in einer Objekteinstellung und die Liste vom Typ „List“ nicht auf die gleiche Weise funktionieren.

Für mich ist das Schreiben von "everyone" wird auch zu "trust_level_0" führen, da dies für Besucher nicht funktioniert anders als in der neuen Version, in der das Dropdown explizit "anonymous_users" anbietet – auch wenn ich sage, dass es nicht funktionieren wird. Wenn es ausgereicht hätte, dies in der Beschreibung zu erwähnen, hättest du dasselbe für Site-Einstellungen tun können. Für den Administrator, der beide Einstellungstypen verwendet, wird es schwierig sein zu verstehen, warum in einigen Fällen die Gruppen, die nicht funktionieren, ausgeblendet sind, und in anderen Fällen nicht – nicht weil der Komponistenschöpfer sich nicht gekümmert hat, sondern weil es an dieser Stelle noch nicht möglich ist.

2 „Gefällt mir“
18

Okay, danke, dass du Beispiele gefunden hast. Ich werde diese Änderung in die Theme-Einstellungsobjekte mit dem Gruppentyp integrieren müssen. Dieses hier zum Beispiel aus den Gruppen-Sidebar-Menüs, ich denke, ich würde es auf die gleiche Weise funktionieren lassen, sodass du dies in der Konfiguration hast:

groups:
  type: groups
  required: true
  resolve_group_memberships: true
  validations:
    max: 20

Dann würde groups auf der Client-Seite zu user_in_groups als boolescher Wert werden.

Die disallowed_groups-Funktionalität ist vielleicht tatsächlich nicht zu schwer… wenn man das obige Beispiel nimmt, würde man am Ende dies haben, um anonymous_users zu entfernen:

groups:
  type: groups
  required: true
  resolve_group_memberships: true
  disallowed_groups: "4"
  validations:
    max: 20

Und für die regulären Gruppentyp-Theme-Einstellungen:

copy_button_allowed_groups:
  type: list
  list_type: group
  default: "11" # trust_level_1
  disallowed_groups: "4" # anonymous_users
  description: "Wählen Sie die Gruppen aus, die die Kopier-Schaltfläche verwenden dürfen."
  resolve_group_membership: true

Ich werde sehen, ob ich diese Funktionalität hinzufügen kann.