Autorizzazioni delle categorie e i nuovi gruppi di autorizzazioni

Quando si aggiungono gruppi a una categoria, è possibile selezionare le opzioni anonymous_users e logged_in_users, ma non funzionano.

2 Mi Piace

Non richiede l’attivazione della funzione beta “Autorizzazioni granulari per gruppi anonimi e connessi”?

1 Mi Piace

Sì, questo si verifica con quella funzione abilitata, che ora è l’impostazione predefinita.

3 Mi Piace

@martin hai qualche idea su questo?

1 Mi Piace

Grazie per il report, darò un’occhiata :eyes:

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) :grimacing: )

Il mio suggerimento sarebbe:

  • rimuovere anonymous_users come opzione per le autorizzazioni delle categorie del tutto
  • mantenere everyone e logged_in_users
  • rimuovere trust_level_0 come opzione poiché equivale a logged_in_users

o in alternativa, ma forse meno chiaro per gli amministratori meno esperti

  • rimuovere anonymous_users e logged_in_users come opzione per le autorizzazioni delle categorie
  • mantenere everyone (e TL0)

In tutti i casi, mantenere everyone. E non avrai nemmeno bisogno di una migrazione :wink:

3 Mi Piace

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” :smiley:

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.

1 Mi Piace

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.

1 Mi Piace

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.

1 Mi Piace

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?

1 Mi Piace

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.