Quando si aggiungono gruppi a una categoria, è possibile selezionare le opzioni anonymous_users e logged_in_users, ma non funzionano.
Non richiede l’attivazione della funzione beta “Autorizzazioni granulari per gruppi anonimi e connessi”?
@martin hai qualche idea su questo?
Grazie per il report, darò un’occhiata ![]()
Dalla tua risposta nell’altro argomento
Più ci penso, più mi preoccupa.
Cosa succede se aggiungo solo anonymous_users a una categoria e non aggiungo logged_in_users?
Cosa succede se aggiungo anonymous_users mentre il mio forum ha login_required (accesso obbligatorio)?
Inoltre, l’implementazione tecnica attuale è che quando le autorizzazioni di categoria sono impostate su everyone, non c’è semplicemente alcuna voce in category_groups e read_restricted è impostato su false.
È molto semplice e diretto: se non sono impostate autorizzazioni, queste sono determinate dalle autorizzazioni globali del forum (l’impostazione login_required) e non si applicano ulteriori restrizioni.
Quindi apportare questa modifica aggiungerebbe un’enorme quantità di complessità e sarebbero possibili combinazioni strane (potresti avere anonymous users (utenti anonimi) e staff (personale)
)
Il mio suggerimento sarebbe:
- rimuovere
anonymous_userscome opzione per le autorizzazioni delle categorie del tutto - mantenere
everyoneelogged_in_users - rimuovere
trust_level_0come opzione poiché equivale alogged_in_users
o in alternativa, ma forse meno chiaro per gli amministratori meno esperti
- rimuovere
anonymous_userselogged_in_userscome opzione per le autorizzazioni delle categorie - mantenere
everyone(e TL0)
In tutti i casi, mantenere everyone. E non avrai nemmeno bisogno di una migrazione ![]()
Grazie per i tuoi pensieri, è per questo che non volevo entrare troppo nel dettaglio delle autorizzazioni delle categorie all’inizio con quella modifica “per tutti” ![]()
Penso che gran parte di ciò che dici qui potrebbe semplicemente essere reso impossibile, ho già lavorato su alcuni sistemi preliminari qui con gli ACL e un’interfaccia utente delle autorizzazioni più user-friendly sul nostro plugin kanban che stiamo sviluppando, ecco un esempio, intendiamo modificare le autorizzazioni delle categorie per utilizzare questo in futuro:
Ci sono diverse regole coinvolte qui, come l’impossibilità di assegnare agli utenti anonimi autorizzazioni di Manager per una bacheca kanban e così via, e supporta anche autorizzazioni obbligatorie, come il fatto che gli Admin possono sempre gestire una bacheca.
Renderemmo impossibile aggiungere utenti anonimi quando il forum richiede l’accesso.
Ancora una volta, un’altra validazione/restrizione che possiamo aggiungere.
Potremmo aggiungere anche validazioni/avvisi per questo tipo di situazioni.
Questo è ciò che voglio evitare, questo tipo di autorizzazioni implicite che sono ovunque in Discourse, piuttosto che avere utenti connessi + utenti anonimi esplicitamente configurati sempre per una categoria se è pubblica/non limitata alla lettura.
Comunque, per ora non voglio entrare troppo in profondità in questo, c’è ancora un po’ di strada da fare prima di occuparmi delle categorie. Ma sono d’accordo che l’OP è un bug che deve essere corretto nel frattempo, quindi procederò comunque.
Tenendo presente quel altro problema, personalmente sconsiglierei questo tipo di logica. Cosa succede se modifico un forum per richiedere l’accesso quando gli utenti anonimi sono già presenti nell’elenco dei permessi? E viceversa? Questo sarebbe un incubo e non sarebbe trasparente per gli amministratori.
Sono molto diffidente verso una complessità di questo tipo.
Ancora una volta, ottimi punti: c’è molto da riflettere e la questione è delicata. Quando apporterò modifiche relative alle categorie, terrò sicuramente a mente l’esperienza degli amministratori; c’è una lunga storia alle spalle e non voglio che nessuno sia preso alla sprovvista. Nulla di tutto questo avverrà in fretta: ci vorrà molto tempo per analizzare attentamente i diversi scenari quando mi occuperò di questo progetto.
Mi chiedo perché il fatto che si possano configurare impostazioni per gli utenti anonimi ma non per quelli connessi sia considerato un problema nel contesto dei permessi di categoria, mentre non lo sia nel contesto dei permessi configurati tramite le impostazioni del sito/plugin/tema. Un esempio semplice: ora è possibile rendere il styleguide disponibile per gli utenti anonimi senza aggiungere gli utenti connessi. Ha più senso di mostrare una categoria agli utenti anonimi ma non a quelli connessi?
No, non ha senso, è solo un altro caso limite da gestire… aggiungerò anonymous_users a disallowed_groups per quel plugin. Inoltre, dubito fortemente che ci siano molti siti in circolazione con questo plugin abilitato, quindi al momento non sono troppo preoccupato che possa essere configurato in modo errato.
Penso che sia il modo in cui gestirei generalmente questo tipo di impostazioni. Possiamo anche sfruttare mandatory_values per assicurarci che determinati gruppi siano sempre selezionati, così da evitare di ritrovarci con solo anonymous_users in alcuni casi. Oppure possiamo usare le convalide delle impostazioni per specificare “non puoi scegliere anonymous_users senza almeno un gruppo di utenti autenticati”, e così via.
Non capisco perché sia necessario. C’è qualcosa che non va nel fatto che sia un’opzione?
Questo funziona solo per le impostazioni del sito, o anche per i componenti del tema?
Al momento non funziona ancora per i componenti del tema, ma potrebbe farlo. Stiamo davvero andando troppo in là con le idee.

