Permessi granulari basati su gruppi per utenti anonimi e registrati

[martin (Martin Brennan)]

@merefield

quindi alcune persone sono state confuse dal fatto che “everyone” significasse solo gli utenti registrati?

chi?!

“everyone” è “everyone”, no? - molto chiaro.

No, non lo era, e lo abbiamo visto emergere più e più volte internamente ed esternamente, e in tutto il codice.

@merefield

quindi ora una Categoria che è completamente pubblica deve avere un minimo di due gruppi invece di uno - registrato e anonimo? è assurdo e non è un miglioramento?

Non sono ancora arrivato alle categorie, qui non è cambiato nulla.

@merefield

cambiando solo TL0 in “utenti registrati” ora si rompe la coerenza di ogni livello di sicurezza come soglia. TL1 è anche una soglia e non proprio un “singolo gruppo”. quindi significa che abbiamo bisogno di un gruppo chiamato “utenti registrati che sono almeno al livello di fiducia 1”?!

Le persone usavano in modo schiacciante TL0 per indicare “tutti gli utenti registrati” perché non avevamo un modo migliore di rappresentare questo. Il gruppo logged_in_users almeno è del tutto chiaro su cosa comporta, e non c’è assolutamente nulla che ti impedisca di continuare a usare TL0/TL1 ecc. L’unico gruppo che viene rimosso è everyone.

@merefield

cambiare per il gusto di cambiare

Sì, certo, sto facendo tutto questo solo per “il gusto di cambiare” Ti prego, considera per un momento le tue parole, non abbiamo l’abitudine di fare cose totalmente inutili senza motivo qui. Questo lavoro è in corso da mesi e non sta cambiando direzione.

[merefield (Robert)]

Ok, forse sto fraintendendo questa modifica?

Se la proposta è introdurre:

• anon
• logged in

come gruppi automatizzati

sembra tutto a posto e sono autoesplicativi.

(In realtà mi piace piuttosto! )

Se invece la proposta è in definitiva rimuovere:

• everyone

questo non mi ha senso, poiché everyone fa parte di una serie di gruppi automatizzati che rappresentano soglie di accesso e che includono anche:

• trust_level_0
• trust_leve_1

ecc.

Tutti rappresentano soglie di accesso, incluso everyone.

Il gruppo everyone è aka “trust_level_none”

È un modo conciso per indicare l’accesso pubblico.

Apprezzo che non stiate proponendo di rimuoverlo per le autorizzazioni delle Categorie al momento (), ma personalmente vorrei vedere un impegno a mantenere questo gruppo automatizzato, perché per me almeno ha senso.

e poi perché non permetterne l’utilizzo altrove, proprio come fareste con qualsiasi gruppo automatizzato di livello di fiducia?

altrimenti, ovunque dobbiate esprimere che qualcosa ha “accesso pubblico”, dovrete aggiungere due gruppi, il che sembra una complessità inutile?

a che serve aggiungere logica per “mascherare” “everyone”?

forse un altro approccio alternativo è riconsiderare il nome “everyone” se esiste un nome migliore, ma mantenere il suo significato, la sua funzionalità e la sua disponibilità su tutta la piattaforma, e poi tutti (tosse) saranno contenti?

[martin (Martin Brennan)]

Credo che la distinzione qui riguardi il mantenere un modo comodo per selezionare “accesso pubblico” e il mantenere il gruppo everyone esistente. Concordo sul fatto che dover selezionare due gruppi ogni volta che si desidera l’accesso pubblico sia più macchinoso, e possiamo migliorare la situazione con l’interfaccia utente.

Ad esempio, potremmo aggiungere una scorciatoia “Pubblico” al selettore di gruppi che selezioni sia anonymous_users che logged_in_users con un’unica azione. Vedresti quindi entrambi i gruppi selezionati e potresti rimuoverne uno. Questo ti darebbe la comodità che stai descrivendo, mantenendo al contempo i permessi sottostanti espliciti. Offriremmo quella scorciatoia solo dove entrambi i gruppi sono consentiti.

Il problema con il mantenere il gruppo everyone esistente è che non ha sempre significato “accesso pubblico”. Per la visibilità delle categorie lo fa, ma per la maggior parte delle impostazioni basate sui gruppi del sito ha effettivamente significato “tutti gli utenti connessi”. Inoltre, ci sono temi e plugin che lo interpretano in modo diverso, come ha mostrato la discussione sopra.

Quindi non possiamo semplicemente mantenerlo e dire che include gli utenti anonimi ovunque, senza il rischio di concedere un accesso che prima non c’era. Mantenere il suo comportamento esistente preserverebbe l’incoerenza, e rinominarlo non risolverebbe il problema.

Un gruppo universale definito in modo coerente sarebbe possibile, ma richiederebbe comunque la migrazione e l’audit che stiamo facendo ora. Dovrebbe anche essere vietato ovunque l’accesso anonimo non sia supportato, altrimenti torneremmo alla situazione in cui “everyone” significa “solo utenti connessi” in quei luoghi. Ci sono un’infinità di impostazioni dove ho dovuto aggiungere anonymous_users come valore di disallowed_groups dove prima non c’era, e dove prima everyone era consentito. Ad esempio:

@martin

A complicare ulteriormente le cose c’è il fatto che questo gruppo @everyone può essere usato in impostazioni del sito dove non ha senso che “tutti gli utenti anonimi e connessi” abbiano accesso alla funzione, come pm_tags_allowed_for_groups.

Preferirei fornire quella comodità nell’interfaccia utente, utilizzando i due gruppi espliciti sottostanti, in modo da avere coerenza ovunque per amministratori e sviluppatori.

[merefield (Robert)]

@martin

Per esempio, potremmo aggiungere una scorciatoia “Pubblico” al selettore di gruppi che seleziona sia anonymous_users che logged_in_users in un’unica azione. Vedresti quindi entrambi i gruppi selezionati e potresti rimuoverne uno. Questo ti darebbe la comodità che stai descrivendo, mantenendo al contempo le autorizzazioni sottostanti esplicite. Offriremmo quella scorciatoia solo dove entrambi i gruppi sono consentiti.

tutti sono molto espliciti - a me sembra una complessità non necessaria - ma apprezzo la comodità mantenuta.

@martin

ma per la maggior parte delle impostazioni del sito basate su gruppi ha significato effettivamente “tutti gli utenti connessi”. Ci sono anche temi e plugin che lo interpretano in modo diverso, come ha mostrato la discussione sopra.

a mio avviso il problema è/lì e non nel concetto originale di categoria “everyone”.

il gruppo “everyone” e il suo utilizzo nel sistema fondamentale delle categorie è presente dal … 2013?

work in progress, add fidelity to category group permissions (full, create posts, readonly)

Se il sistema di impostazioni si è discostato e ha rotto questo contratto, non è un problema del lavoro svolto sul sistema di impostazioni?

A mio avviso sarebbe stato bello avere un RFC per la comunità per contribuire con idee a questo prima di ciò che sembra dirigersi direttamente verso l’implementazione.

Scuse se ho perso qualcosa …

[martin (Martin Brennan)]

Sì, sono d’accordo sul fatto che l’incoerenza nelle impostazioni del sito faccia parte del problema. Ma risolvere questo aspetto non significa necessariamente continuare a utilizzare il gruppo esistente everyone per le impostazioni del sito.

Non credo che l’argomento del 2013 ci dica molto oltre a quanto tempo everyone sia esistito per i permessi delle categorie. Da allora, in Discourse è cambiato un sacco di cose; ad esempio, molte impostazioni del sito erano basate sul livello di fiducia, ora sono basate sui gruppi. Nessuno mette in discussione che abbia senso in quel contesto, e i permessi delle categorie non vengono modificati da questo lavoro (almeno, per ora). Il suo invecchiamento non stabilisce che abbia un significato coerente nel resto di Discourse, o che dovremmo mantenerlo indefinitamente.

Anche se fossimo d’accordo che ogni deviazione dal significato originale fosse un errore, dovremmo comunque affrontare il modo in cui quelle impostazioni si comportano effettivamente sui siti esistenti. Non possiamo modificare in sicurezza la loro interpretazione per includere gli utenti anonimi solo perché ciò corrisponderebbe meglio al comportamento originale delle categorie. Come ho spiegato sopra, mantenere un gruppo universale con un significato coerente richiederebbe comunque di auditare e migrare quegli usi. È un’alternativa di progettazione, ma non evita la parte difficile di questo lavoro.

Per quanto riguarda il punto RFC, avere un RFC della community prima di apportare modifiche come queste sarebbe lento e proibitivo, anche se i feedback sono benvenuti, ed è proprio a questo che serve il sistema di modifiche in arrivo. Questo argomento ha già portato a diversi miglioramenti grazie agli esempi di Moin, e ho riconosciuto i casi di tema/componente che avevo inizialmente trascurato e li ho corretti anch’io.

Sono felice di continuare a lavorare su problemi concreti relativi alla modifica, ma procederò comunque con i due gruppi espliciti. Rendere l’accesso pubblico comodo da selezionare nell’interfaccia sembra un modo ragionevole per affrontare i clic extra, ma non credo che sia necessario implementarlo in questo preciso momento.

Comunque, ho ancora un sacco di lavoro tracciato in The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions per questo, quindi ci vorrà ancora un po’, così come qualsiasi modifica relativa al sistema delle categorie, che per il momento mantiene everyone. Le categorie probabilmente passeranno a un sistema che chiamiamo ACL, che kanban già utilizza: