Nessun problema! Sono felice che disallowed_groups sarà utile. Ho appena unito quella PR.
Devo ora passare in rassegna tutti i nostri temi e componenti ufficiali ora che abbiamo disallowed_groups e resolve_group_memberships disponibili; vi consiglio di fare lo stesso per i vostri temi e componenti quando possibile, poiché dopo aver apportato modifiche ai nostri repository ufficiali vorrei davvero procedere con la stabilizzazione della modifica proposta nel primo messaggio.
C’è molto altro lavoro di base che ora si basa su/utilizza anonymous_users e logged_in_users e vorrei davvero eliminare il gruppo everyone.
ho appena eseguito un aggiornamento completo della mia istanza, e sto ora aggiungendo l’impostazione dell’oggetto disallowed_groups al mio componente per everyone e anonymous_users basandomi sugli ID dei gruppi automatici qui:
cosa sto sbagliando nell’impostazione dell’oggetto? noto che anche senza disallowed_groups negli oggetti, il gruppo anonymous_users non viene comunque mostrato (quindi al momento non c’è differenza nella lista del mio componente tra impostare disallowed_groups o meno). ho testato con altri ID di gruppo e devo stare sbagliando qualcosa nell’uso di disallowed_groups (o nella sintassi) perché sembra non avere alcun effetto indipendentemente da quali ID utilizzo.
Ah, c’erano alcuni problemi su GitHub all’inizio della giornata, quindi solo ora la modifica di disallowed_groups è stata integrata nell’ultimo commit Commits · discourse/discourse · GitHub
Non sono del tutto sicuro che sia questo il problema, ma puoi provare ad aggiornare di nuovo e vedere se persiste? In caso contrario, fammi sapere e indicami il tuo componente del tema (o è solo quello della barra laterale del gruppo?) così posso eseguire il debug
hah grazie Moin! in realtà avevo dimenticato che la nuova impostazione granulare dei gruppi fosse già prevista nei cambiamenti a venire.
Martin, l’impostazione dell’oggetto disallowed_groups funziona perfettamente. mi piace davvero molto questo cambiamento. grazie ancora Team - grande miglioramento.
Ho aperto una PR veloce per aggiungere quelle due classi (anonymous_users e logged_in_users).
Non l’ho testata molto (lol) ma credo sia piuttosto semplice. Il codice controlla solo se l’utente corrente esiste, e se è così, allora è un membro di logged_in_users, e se no, allora è anonymous_users.
nota: sono quasi certo che Discourse aggiunga automaticamente .anon comunque, quindi il CSS per utenti anonimi vs connessi può essere ottenuto senza il componente, ma questo usa semplicemente le nuove convenzioni dei gruppi.
Per completezza, vi informo che non avevo ancora pubblicato qui, ma ho unito queste PR per i componenti ufficiali in modo che utilizzino resolve_group_membership e disallowed_groups:
Sto lavorando a un piano per i prossimi passi di questo imminente cambiamento. Credo che ci siano ancora alcuni punti nei codici sorgente del core/delle plugin che controllano direttamente everyone o non utilizzano user.in_any_groups? sul lato server.
Il motivo per cui ho aperto questo argomento è che alla fine ho aggiornato il mio componente
[quote=“martin, post:14, topic:402273”]
Modificherei il valore predefinito di default_favorite_filters_groups in 4|5 nel tuo componente del tema, che corrisponde agli utenti connessi e anonimi, invece di 0 (everyone) che verrà rimosso a breve.
[/quote]\nL’ho fatto. Ma ho ancora l’impressione che aiuti solo i forum che aggiungono il componente dopo che ho apportato questa modifica. Per quelli che lo utilizzano già, il nuovo valore predefinito non viene applicato (il che di solito è positivo!). Quindi vedo ancora il problema di un cambiamento imprevisto nel comportamento per coloro che utilizzano già il componente.
Inoltre, sai cosa succede se un amministratore ha configurato un’impostazione con un gruppo che aggiungo come gruppo non consentito nel mio aggiornamento?
Poiché non penso che il componente sia utilizzato in molti forum, non mi sono preoccupato troppo e ho unito comunque, ma sia la migrazione che l’impostazione dei gruppi non consentiti potrebbero essere rilevanti anche per altri sviluppatori di temi
No, per qualche motivo immagino che il mio cervello abbia pensato che non si trattasse di una PR nell’organizzazione di Discourse . La unirò subito dopo l’esecuzione dei controlli CI.
Per questi e altri casi futuri, penso che la soluzione migliore sia probabilmente scrivere una migrazione su base tema/componente Migrate Discourse theme settings
Nel mio post sopra ho chiesto quando dovrebbe avvenire questa operazione. Migrare senza essere certi che i nuovi gruppi funzionino su tutti i forum potrebbe anche causare problemi, e gli amministratori possono attivare e disattivare la modifica. Quindi sembra impossibile migrare nel momento giusto.
Mi scuso se questo è già stato menzionato e l’ho perso…
Ho notato che, se resolve_group_membership è incluso nelle impostazioni, posso accedere al valore booleano solo tramite il prefisso user_in_, ma non posso più accedere al valore grezzo del campo delle impostazioni.
aabbccdd_allowed_groups:
refresh: true
default: "1|2"
type: list
list_type: group
resolve_group_membership: true
console.log(settings.aabbccdd_allowed_groups); // undefined
console.log(settings.user_in_aabbccdd_allowed_groups); // true o false
Penso di sì. Altrimenti, la soluzione per questo bug avrebbe potuto essere diversa.
Anche a me ha senso. user_in_x controlla anche i gruppi che il frontend non conosce, perché il gruppo è visibile solo agli amministratori o la sua visibilità è limitata di default, come nel caso di everyone. Quindi ottieni risultati diversi a seconda di cosa usi, quindi combinare i due potrebbe avere conseguenze impreviste.
Grazie Moin, è esattamente così. @gormus l’unico posto in cui i reali ID dei gruppi vengono ancora passati è nell’interfaccia amministrativa per le impostazioni del tema.
Non sono sicuro che sia chiaro basandosi su ciò che ho postato in precedenza, ma anonymous_users e logged_in_users sono utilizzabili in qualsiasi momento senza che questa modifica imminente sia abilitata, li ho aggiunti indipendentemente mesi fa. Questa è la cosa principale che fa la modifica imminente:
Quindi, in ogni caso, sei al sicuro se elimini everyone ovunque venga utilizzato e utilizzi solo anonymous_users e logged_in_users d’ora in poi.
Oggi ho intenzione di definire un piano per il lavoro rimanente che devo fare per eliminare definitivamente everyone dalle impostazioni del sito (lasciando da parte per il momento le impostazioni delle categorie), e lo posterò qui, così spero che aiuterà a rimanere allineati in futuro, e potrò continuare ad aggiornare questo piano man mano che procedo.
Tuttavia, i gruppi non sono visibili nell’interfaccia se la modifica è disabilitata. Gli amministratori non possono modificare un’impostazione relativa a questi gruppi. Quindi, quando aggiungo “tutti” come disallowed_group, non vedono più alcun gruppo che consenta loro di configurare un componente in modo che sia visibile ai visitatori. Per me, “utilizzabile” implica non solo il corretto funzionamento, ma anche la visibilità. Dato che è ancora possibile disabilitare la modifica, non definirei “sicuro” affidarsi esclusivamente ai nuovi gruppi.
Mmm, hai ragione. Ci sono altre due cose che devo sistemare affinché il problema del disallowed_group scompaia quando la modifica imminente è disabilitata:
anonymous_users e logged_in_users non sono presenti nel selettore di gruppi. Penso che sia sicuro consentirli qui, così non avrà importanza se hai aggiunto everyone a disallowed_groups se la modifica imminente è disattivata.
Correggere Guardian::AnonymousUser#in_any_groups? per rispettare anonymous_users quando la modifica imminente è disattivata.
Aggiungere lo stesso aliasing del tempo di lettura 0 (everyone) → 5 (logged_in_users) per le impostazioni del tema, come facciamo per le impostazioni del sito.
Penso che potrei anche contrassegnare everyone con (legacy) nei selettori di gruppi mentre la modifica imminente è ancora opzionale e disabilitata.
Dare priorità a questi punti e li aggiungerò al piano generale su cui sto lavorando.
Ho creato un argomento dedicato qui @moinThe road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions . Il post originale è incompleto, sto ancora esaminando tutti i casi in locale e continuerò a aggiornarlo. Non mi dispiace se continui a pubblicare in questo argomento, ma preferirei che portassimo le discussioni successive in quello nuovo, così da poter citare parti del post originale o aggiungerne altre dove opportuno.
grazie Moin! in realtà avevo dimenticato che la nuova impostazione granulare dei gruppi fosse già prevista nei cambiamenti a venire.
. La unirò subito dopo l’esecuzione dei controlli CI.