Permessi granulari basati su gruppi per utenti anonimi e registrati

Notizie ed Eventi Annunci
1

Nel nostro codice esiste storicamente un pseudogruppo confuso chiamato @everyone, che può essere utilizzato per:

  • Impostazioni del sito di tipo group_list
  • Permessi delle categorie
  • Gruppi di tag

In alcuni casi, le persone interpretano @everyone come “tutti gli utenti anonimi e tutti gli utenti registrati”, mentre altre lo intendono come solo “tutti gli utenti registrati”. La realtà, per le impostazioni del sito, è che nella maggior parte dei casi significa solo “tutti gli utenti registrati”.

A complicare ulteriormente le cose è il fatto che questo gruppo @everyone può essere utilizzato in impostazioni del sito dove non ha senso concedere l’accesso a “tutti gli utenti anonimi e registrati”, come ad esempio pm_tags_allowed_for_groups.

Questa situazione crea confusione anche dal punto di vista del feature flagging e dell’esperienza degli sviluppatori, poiché per alcune modifiche future o altre impostazioni potremmo voler abilitarle realmente per “tutti gli utenti anonimi e registrati”.

Soluzione

Stiamo introducendo due nuovi pseudogruppi automatici distinti:

  • anonymous_users (ID 4) - Rappresenta gli utenti anonimi che visitano il tuo sito senza un account
  • logged_in_users (ID 5) - Rappresenta tutti gli utenti registrati del tuo sito, con un effetto simile al gruppo automatico trust_level_0, ma più specifico

Questi gruppi sono già stati introdotti, ma avranno effetto solo quando la modifica futura granular_anonymous_and_logged_in_groups_permissions verrà abilitata sul tuo sito.

Quando la modifica futura sarà abilitata, qualsiasi impostazione con everyone come gruppo selezionato verrà automaticamente tradotta nell’ID logged_in_users, quindi nessun dato nella tabella delle impostazioni del sito verrà modificato al momento dell’attivazione della modifica futura. Quando la modifica futura diventerà permanente, eseguirò una migrazione dei dati per tutte le impostazioni dei gruppi per applicare questa modifica.

Inoltre, abbiamo segnato anonymous_users come disallowed_group per diverse impostazioni del sito dove non ha senso, ad esempio personal_message_enabled_groups.

image
image1217×205 51.6 KB

I conflitti con i nomi di gruppi esistenti vengono gestiti automaticamente, rinominando i gruppi esistenti e aggiornando le menzioni nei post.

E per i permessi di tag e categoria?

Questi permessi rimarranno invariati, poiché il loro concetto di “everyone” è diverso in alcuni aspetti e non si basa sul gruppo automatico sottostante.

9 Mi Piace
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

Aspetta… cosa? :flushed_face: Significa che tutte le categorie che sono ora pubbliche (tutti) diventeranno chiuse e richiederanno l’accesso quando questa funzionalità verrà attivata?

4

No, perché:

Questo influisce solo sulle impostazioni del sito di tipo elenco gruppi che attualmente permettono di selezionare “tutti” come segue:

image
image909×273 54 KB

1 Mi Piace
5

Qualcuno può aiutarmi a capire come devo modificare i componenti del mio tema?

Ho provato a usare il componente copy-post come esempio, perché ricordo che utilizza anche un’impostazione di gruppo che concede l’accesso alla funzionalità. E che c’era un problema perché il gruppo fittizio “everyone” richiedeva un controllo separato, proprio come nel mio componente, poiché il confronto degli ID dei gruppi a cui l’utente appartiene non è sufficiente: quegli ID devono essere verificati separatamente. Per questo motivo mi aspettavo un recente cambiamento lì, perché, per quanto ne so, anche i nuovi gruppi sono gruppi fittizi e l’ID dovrebbe essere verificato separatamente. Mi sto perdendo qualcosa che spieghi perché ciò non sia necessario qui?

Il mio componente favorite filters ha due impostazioni di gruppo: una che permette ai gruppi di salvare i propri filtri e una che offre filtri standard.
Di default, solo i membri del gruppo trust_level_0 possono utilizzare filtri personalizzati, poiché solo gli utenti registrati possono avere dati memorizzati in un campo utente personalizzato. Quindi qui avrebbe senso se non permettessi anonymous_users come selezione. Come posso farlo in un componente del tema? Esiste già un esempio per questo?

L’impostazione predefinita per i filtri predefiniti è «everyone», perché trovo utile che anche gli utenti non registrati possano vedere e utilizzare i filtri predefiniti. Il problema è che everyone cambia in «logged_in_users» anche se l’ho selezionato specificamente. Devo creare una migrazione personalizzata per questo, in modo che gli amministratori che attualmente utilizzano everyone continuino ad avere filtri per gli utenti non registrati in futuro? Quando deve avvenire questa migrazione? O ogni amministratore deve modificarlo individualmente dopo che hai eseguito la migrazione?

Tutto ciò di cui mi sto preoccupando è davvero inutile? Se sono necessarie modifiche, meno di quattro settimane sembrano un lasso di tempo piuttosto breve, dato il numero di componenti mantenuti dalla comunità che potrebbero essere potenzialmente interessati.
Oltre a «copy-post», ho anche esaminato il componente unanswered filter, ma non ho trovato alcun cambiamento nemmeno lì. Sembra che stia trascurando qualcosa di importante. Dopo tutto, la modifica è stata abilitata di default da quasi una settimana. Per questo motivo ipotizzo che i componenti ufficiali sarebbero già stati aggiornati se fossero state necessarie modifiche.

1 Mi Piace
6

3 post sono stati uniti in un argomento esistente: Modernizzazione del tema Foundation

7

Guardando questi componenti, currentUser?.groups non è comunque affidabile, poiché include solo i gruppi visibili per l’utente, mentre i gruppi in cui si trova e che influenzano i permessi potrebbero non essere serializzati qui:

Nei core/plugins aggiriamo il problema facendo cose del genere nel serializzatore dell’utente corrente:

Ma ovviamente, questo non è disponibile per i componenti del tema e i relativi impostazioni.

Hmm, non sono sicuro, ci devo pensare. Se intendevi davvero everyone, allora dovrebbe essere cambiato sia in logged_in_users CHE in anonymous_users. Questo era il problema principale di everyone, come dichiarato nel post originale: alcuni pensavano significasse solo utenti loggati, altri intendevano loggati + anonimi, ed era molto dipendente dalla situazione.

Ho scelto l’interpretazione «solo utenti loggati» perché era più sicura dal punto di vista della sicurezza.

No, semplicemente non ho considerato i componenti del tema e le relative impostazioni e come sarebbero stati influenzati da questa modifica; mi ero concentrato principalmente sulle impostazioni del sito. Cose del genere saranno particolarmente difficili da individuare, dato che non utilizza nemmeno la costante AUTO_GROUPS:

image

Comunque, elaborerò alcune soluzioni a questi problemi e non sposterò questa modifica su Stable finché non avrò trovato una soluzione.

3 Mi Piace
Introducing Upcoming Changes, a system to manage new features and changes to existing functionality in your community
9

Aggiornamento rapido: ho un’idea su come gestire la cosa e stiamo conducendo alcune discussioni interne al riguardo. Spero non richieda troppo tempo :crossed_fingers:

1 Mi Piace
10

Questo sono esattamente io :upside_down_face:; quindi, per creare una categoria riservata solo agli utenti registrati, ho impostato il permesso di accesso solo a TL0, affidandomi al gruppo utente automatico TL0 per distinguere gli utenti connessi dai visitatori.

Mi chiedo se esista una tabella per distinguere il significato di questo termine in diversi contesti. Queste differenze sono sia confuse che inquietanti: perché quando le persone hanno scelto questa impostazione, probabilmente non ne conoscevano il significato reale, quindi vorranno verificare le impostazioni correlate. Al momento, posso solo controllare singolarmente ogni luogo in cui sono impostati i gruppi e confermare cosa significava in base a chi è stato modificato dopo l’attivazione della funzione dei gruppi granulari, il che mi fa sentire come se steggiando al buio.

2 Mi Piace
11

È una buona idea…potrei riuscire a far fare qualcosa all’IA per cercare in tutti i luoghi in cui vengono utilizzate le impostazioni basate sui gruppi e dire se è anche possibile per anonymous accedere a queste cose.

Ci sono un mucchio di impostazioni che già impediscono la selezione del gruppo anonymous_users, quindi quelle sono probabilmente un buon punto di partenza…riporterò qui i risultati.

Ho delle PR per questo su cui sto lavorando ora:

Ci saranno altre PR e modifiche alla documentazione poco dopo.

3 Mi Piace
12

@Noble_Fish, questa è la lista generata dall’IA delle impostazioni basate sui gruppi, a cosa serve ogni impostazione e come gli utenti anonimi/effettuati l’accesso si applicano a tale impostazione. Tieni presente che sono ragionevolmente sicuro che sia corretta, ma come per qualsiasi contenuto generato dall’IA, è buona norma verificare i fatti personalmente.

Penso che la colonna più interessante sia “everyone includeva anche anonymous_users prima del cambiamento?”, se è Sì significa che everyone significava utenti connessi E anonimi prima che venisse applicato questo imminente cambiamento.

Come puoi vedere, ce ne sono solo pochi lì dentro, quindi sono gli unici che un amministratore dovrebbe aggiungere esplicitamente anonymous_users nelle impostazioni del sito:

  • hidden_post_visible_groups - Devo effettivamente modificare questa per consentire anonymous_users, il codice non è del tutto corretto per questo imminente cambiamento.
  • lazy_load_categories_groups - Devo correggere anche questa, fa un controllo ridondante di everyone che è già fatto dentro user.in_any_groups?
  • styleguide_allowed_groups - Funziona così com’è, ma la modificherò leggermente anche questa

Quando questo imminente cambiamento diventerà permanente, i gruppi logged_in_users e anonymous_users saranno usati esclusivamente, e everyone verrà eliminato.

Impostazione Descrizione Si applica logged_in_users? Si applica anonymous_users? everyone includeva anche anonymous_users prima del cambiamento? Trovato nel codice
whispers_allowed_groups Consenti la comunicazione privata all’interno degli argomenti per i membri dei gruppi specificati. No No No everyone, logged_in_users e anonymous_users sono vietati; il runtime si aspetta anche l’appartenenza a gruppi concreti.
hidden_post_visible_groups Consenti ai membri di questi gruppi di visualizzare i post nascosti. Gli utenti dello staff possono sempre visualizzare i post nascosti. Sì No Sì Controlla everyone prima di rifiutare gli utenti anonimi; altrimenti usa in_any_groups?.
about_page_hidden_groups Non mostrare i membri di gruppi specifici nella pagina /about. No No No Usa group_users; i pseudogruppi non hanno righe di membri.
about_page_extra_groups Gruppi da mostrare nella pagina about sotto i moderatori. No No No Carica gruppi concreti e membri per la visualizzazione.
anonymous_posting_allowed_groups Gruppi a cui è consentito abilitare la pubblicazione anonima. Sì No No Controllo utente connesso tramite in_any_groups?; anonymous_users è vietato.
personal_message_enabled_groups Consenti agli utenti in questi gruppi di creare messaggi personali. Sì No No Controllo utente connesso tramite in_any_groups?; anonymous_users è vietato.
shared_drafts_allowed_groups Consenti agli utenti in questi gruppi di vedere e modificare le bozze condivise. Sì No No Controllo guardian utente; anonymous_users è vietato.
here_mention_allowed_groups Gruppi a cui è consentito menzionare @here. Sì No No Richiede utente autenticato; anonymous_users è vietato.
approve_unless_allowed_groups I post di utenti non in questi gruppi devono essere approvati. Sì No No Controllo utente tramite in_any_groups?; anonymous_users è vietato.
approve_new_topics_unless_allowed_groups I nuovi argomenti creati da utenti non in questi gruppi devono essere approvati. Sì No No Controllo utente tramite in_any_groups?; anonymous_users è vietato.
skip_review_media_groups Gli utenti al di fuori di questi gruppi hanno i post con media incorporati inviati per la revisione. Sì No No Controllo utente tramite in_any_groups?; anonymous_users è vietato.
content_localization_allowed_groups Gruppi autorizzati ad aggiornare i contenuti localizzati. Sì No No Controllo guardian/utente; anonymous_users è vietato.
email_in_allowed_groups Gruppi a cui è consentito pubblicare nuovi argomenti tramite e-mail. Sì No No Controllo utente mittente e-mail; anonymous_users è vietato.
view_raw_email_allowed_groups Gruppi che possono visualizzare il contenuto grezzo delle e-mail in arrivo. Sì No No Controllo utente guardian; anonymous_users è vietato.
uploaded_avatars_allowed_groups Specifica i gruppi autorizzati a caricare immagini del profilo personalizzate. Sì No No Controllo utente corrente/target; anonymous_users è vietato.
create_topic_allowed_groups Gruppi a cui è consentito creare nuovi argomenti. Sì No No Richiede utente e usa in_any_groups?; anonymous_users è vietato.
topic_timers_allowed_groups Gruppi a cui è consentito impostare i timer degli argomenti. Sì No No Controllo utente guardian; anonymous_users è vietato.
edit_wiki_post_allowed_groups Gruppi a cui è consentito modificare i post contrassegnati come wiki. Sì No No Controllo utente guardian; anonymous_users è vietato.
edit_post_allowed_groups Gruppi a cui è consentito modificare i post. Sì No No Controllo utente guardian; anonymous_users è vietato.
self_wiki_allowed_groups Consenti agli utenti in questi gruppi di rendere i propri post wiki. Sì No No Controllo utente guardian; anonymous_users è vietato.
send_email_messages_allowed_groups Gruppi a cui è consentito inviare messaggi personali tramite e-mail. Sì No No Controllo utente guardian; anonymous_users è vietato.
flag_post_allowed_groups Gruppi a cui è consentito segnalare i post. Sì No No Controllo utente guardian; anonymous_users è vietato.
post_links_allowed_groups Gruppi a cui è consentito includere link nei post. Sì No No Richiede utente autenticato; anonymous_users è vietato.
embedded_media_post_allowed_groups Gli utenti in questi gruppi possono incorporare elementi multimediali in un post. Sì No No Controllo utente agente; anonymous_users è vietato.
profile_background_allowed_groups Gruppi a cui è consentito caricare uno sfondo del profilo. Sì No No Controllo utente; anonymous_users è vietato.
user_card_background_allowed_groups Gruppi a cui è consentito caricare uno sfondo della scheda utente. Sì No No Controllo utente; anonymous_users è vietato.
invite_allowed_groups Gruppi a cui è consentito invitare utenti. Sì No No Controllo utente guardian; anonymous_users è vietato.
ignore_allowed_groups Gruppi a cui è consentito ignorare altri utenti. Sì No No Controllo utente guardian; anonymous_users è vietato.
delete_all_posts_and_topics_allowed_groups Gruppi autorizzati a eliminare post e argomenti creati da altri utenti e a vedere i contenuti eliminati. Sì No No Controllo guardian/utente corrente; anonymous_users è vietato.
edit_all_topic_groups Consenti agli utenti in questo gruppo di modificare i titoli degli argomenti, i tag e le categorie di altri utenti. Sì No No Divisione grezza poi in_any_groups?; anonymous_users è vietato.
edit_all_post_groups Consenti agli utenti in questo gruppo di modificare i post di altri utenti. Sì No No Controllo utente tramite in_any_groups?; anonymous_users è vietato.
change_post_ownership_allowed_groups Consenti agli utenti in questi gruppi di modificare la proprietà dei post. Sì No No Controllo utente corrente; anonymous_users è vietato.
cross_origin_opener_unsafe_none_groups Gruppi di override COOP nascosti; gli utenti corrispondenti ricevono Cross-Origin-Opener-Policy: unsafe-none. Sì No No Richiede current_user.present?; la selezione anonima non ha effetto runtime.
user_api_key_allowed_groups Appartenenza al gruppo richiesta per la generazione di chiavi API utente. Sì No No Controllo utente corrente; anonymous_users è vietato.
create_tag_allowed_groups Gruppi a cui è consentito creare tag. Sì No No Controllo utente guardian; anonymous_users è vietato.
edit_tags_allowed_groups Gruppi a cui è consentito modificare tag, descrizioni dei tag e sinonimi dei tag. Sì No No Controllo utente guardian; anonymous_users è vietato.
tag_topic_allowed_groups Gruppi a cui è consentito taggare gli argomenti. Sì No No Controllo utente guardian; anonymous_users è vietato.
pm_tags_allowed_for_groups Consenti ai membri dei gruppi inclusi di taggare qualsiasi messaggio personale. Sì No No Controllo utente guardian; anonymous_users è vietato.
lazy_load_categories_groups Caricamento lento delle informazioni sulla categoria solo per gli utenti di questi gruppi. Sì Sì Sì Controllo esplicito di everyone più guardian in_any_groups?; anonymous_users è significativo.
chat_allowed_groups Gli utenti in questi gruppi possono chattare, tranne gli utenti anonimi che possono solo visualizzare la chat quando aggiunti a questa impostazione. Sì Sì No La chat connessa usa in_any_groups?; la chat pubblica anonima controlla esplicitamente anonymous_users.
direct_message_enabled_groups Consenti agli utenti all’interno di questi gruppi di creare Chat Personali utente-utente. Sì No No Controllo guardian chat connesso; nessun percorso DM anonimo significativo.
chat_pinning_messages_allowed_groups Gli utenti in questi gruppi possono fissare i messaggi della chat. Sì No No Richiede accesso alla chat/utente corrente; nessun percorso di fissaggio anonimo.
chat_message_flag_allowed_groups Gli utenti in questi gruppi possono segnalare i messaggi della chat. Sì No No Controllo utente; il percorso anonimo è bloccato dalle autorizzazioni della chat circostanti.
no_ads_for_groups Non mostrare annunci agli utenti in questi gruppi. Sì No No Aggiunto solo al serializzatore current_user; nessun payload utente corrente anonimo.
adsense_exclude_groups Gli annunci non verranno mostrati ai membri di questi gruppi. Sì No No Flag annuncio utente corrente tramite in_any_groups?; nessun payload utente corrente anonimo.
dfp_exclude_groups Gli annunci non verranno mostrati ai membri di questi gruppi. Sì No No Flag annuncio utente corrente tramite in_any_groups?.
amazon_exclude_groups Gli annunci non verranno mostrati ai membri di questi gruppi. Sì No No Flag annuncio utente corrente tramite in_any_groups?.
carbonads_exclude_groups Gli annunci non verranno mostrati ai membri di questi gruppi. Sì No No Flag annuncio utente corrente tramite in_any_groups?.
adbutler_exclude_groups Gli annunci non verranno mostrati ai membri di questi gruppi. Sì No No Flag annuncio utente corrente tramite in_any_groups?.
composer_ai_helper_allowed_groups Gli utenti in questi gruppi vedranno il pulsante di assistenza AI nel compositore. Sì No No Controllo assistenza AI connesso tramite in_any_groups?.
post_ai_helper_allowed_groups Gruppi di utenti autorizzati ad accedere alle funzionalità di AI Helper nei post. Sì No No Controllo assistenza AI connesso tramite in_any_groups?.
ai_pm_summarization_allowed_groups Gruppi autorizzati a creare e visualizzare riepiloghi nei messaggi personali. No No No Usa user.group_ids grezzi, quindi i pseudogruppi non corrispondono.
ai_bot_debugging_allowed_groups Consenti a questi gruppi di vedere un pulsante di debug che mostra la richiesta e la risposta grezze dell’IA. Sì No No Restituisce esplicitamente false per anonimo, poi usa in_any_groups?.
ai_bot_allowed_groups Quando il Bot GPT ha accesso al messaggio personale, risponderà ai membri di questi gruppi. Sì No No I controlli primari usano in_any_groups?; un percorso playground usa group_ids grezzi.
ai_bot_public_sharing_allowed_groups Consenti a questi gruppi di condividere messaggi personali AI con il pubblico tramite un link univoco. Sì No No Restituisce esplicitamente false per anonimo, poi usa in_any_groups?.
assign_allowed_on_groups Gli utenti in questi gruppi possono assegnare argomenti. No No No Usa user.group_ids/GroupUser grezzi; i pseudogruppi non hanno righe.
discourse_post_event_allowed_on_groups Gruppi a cui è consentito creare eventi. No No No groups.where(id: ...) grezzo; everyone è trattato in modo speciale, ma logged_in_users no.
discourse_kanban_manage_board_allowed_groups Gruppi autorizzati a creare e configurare board kanban. Sì No No Il guardian usa in_any_groups?, ma i controller di scrittura richiedono l’accesso.
create_policy_allowed_groups Appartenenza al gruppo richiesta per aggiungere policy ai post. Sì No No Controllo post/utente tramite in_any_groups?.
flag_posts_voting_comments_allowed_groups Gruppi autorizzati a segnalare un commento di voto su un post. Sì No No Controllo utente tramite in_any_groups?.
allow_solved_in_groups Consenti di contrassegnare le soluzioni nei messaggi di gruppo per questi gruppi. Nessun controllo utente Nessun controllo utente Nessun controllo utente Corrisponde a topic.allowed_groups del messaggio personale, non all’appartenenza dell’utente corrente.
accept_all_solutions_allowed_groups Gruppi a cui è consentito accettare soluzioni su qualsiasi argomento. Sì No No Controllo utente autenticato/corrente tramite in_any_groups?.
discourse_templates_groups_allowed_private_templates Gruppi autorizzati a usare template privati. No No No GroupUser.exists? grezzo; solo everyone è trattato in modo speciale.
poll_create_allowed_groups I gruppi a cui è consentito creare sondaggi. Sì No No Controllo utente agente/corrente tramite in_any_groups?.
styleguide_allowed_groups Limita la visibilità dello styleguide ai membri dei gruppi forniti. Sì Sì Sì Il controller gestisce esplicitamente anonymous_users; consentiva anche l’accesso anonimo tramite everyone prima del cambiamento.
2 Mi Piace
13

Separa queste modifiche in una nuova PR:

2 Mi Piace
14

@moin questa PR DEV: Add resolve_group_membership functionality to theme settings - Pull Request #41360 - discourse/discourse - GitHub è stata ora unita e sto aggiungendo la documentazione in DEV: Docs for theme setting resolve_group_membership - Pull Request #41537 - discourse/discourse - GitHub. Ho corretto discourse-copy-post con DEV: Use resolve_group_membership core theme functionality - Pull Request #37 - discourse/discourse-copy-post - GitHub e ora sto esaminando i nostri altri plugin ufficiali per vedere se ce ne sono altri che necessitano dello stesso trattamento (ad esempio, hai già indicato GitHub - discourse/discourse-unanswered-filter · GitHub).

Per il tuo Filter Favorites, puoi vedere l’esempio di copy-post che ho realizzato, ma fondamentalmente devi aggiungere resolve_group_membership: true sia a default_favorite_filters_groups che a custom_favorite_filters_allowed_groups. In questo modo saranno disponibili come valori booleani in base all’appartenenza dell’utente ai gruppi nelle settings come settings.user_in_default_favorite_filters_groups e settings.user_in_custom_favorite_filters_allowed_groups rispettivamente, e ora non è più necessario controllare manualmente gli ID dei gruppi degli utenti nel frontend.

Modificherei il valore predefinito di default_favorite_filters_groups in 4|5 nel tuo componente tema, che corrisponde agli utenti connessi e anonimi, invece di 0 (everyone) che verrà rimosso a breve.

Prenderò nota di eseguire una migrazione del database sulle impostazioni dei temi quando eliminerò il gruppo “tutti”; dovrò farne una anche per le impostazioni del sito. Questo avverrà quando la modifica imminente diventerà permanente nelle prossime settimane (a seconda di eventuali altri problemi che potrebbero sorgere e di quanto velocemente riuscirò a correggere altri temi/componenti che necessitano dell’aggiunta di resolve_group_membership).

Al momento non esiste un modo per farlo come per le impostazioni del sito… Non penso che sia necessario aggiungerlo ora, puoi semplicemente menzionarlo nella descrizione dell’impostazione e usare currentUser nel frontend per proteggere l’accesso. Forse in futuro lo aggiungerò se ci sarà più bisogno.

2 Mi Piace
15

Funziona anche per il tipo groups nelle impostazioni degli oggetti?

16

No, è necessario? Non ne ero a conoscenza, non so se venga utilizzato per i permessi o meno.

17

Penso che venga utilizzato, ad esempio, in Discourse Group Sidebar Menus in modo che gli amministratori possano configurare quali gruppi dovrebbero poter visualizzare ciascuna sezione della barra laterale, e viene utilizzato in Notification Banners per configurare la visibilità di ogni banner.

Presumevo che lo avresti usato anche nel tuo componente ads. Ma sembra che si basi invece su una stringa di nomi di gruppi.

Cerco di preferire le impostazioni di tipo gruppo, perché aiutano l’amministratore a inserire facilmente i gruppi con un menu a discesa, mentre si basano su ID di gruppo, che è meno probabile che cambino rispetto ai nomi. E penso sia confuso se l’elenco dei gruppi in un’impostazione oggetto e il tipo elenco non funzionano allo stesso modo.

Per me, scrivere "everyone" risulterà anche in "trust_level_0" perché questo non funziona per i visitatori è diverso dalla nuova versione, dove il menu a discesa offre esplicitamente "anonymous_users" - anche se dico che non funzionerà. Se dirlo nella descrizione fosse stato sufficiente, avresti potuto fare lo stesso per le impostazioni del sito. Per l’amministratore che utilizza entrambi i tipi di impostazioni, sarà difficile capire perché, in alcuni posti, i gruppi che non funzionano sono nascosti, e in altri no - non perché il creatore del componente non si sia preoccupato, ma perché non è ancora possibile in quel punto.

2 Mi Piace