Ecco cosa otteniamo quando proviamo a creare una sottocategoria per gli amministratori (stesso problema per i moderatori) all’interno della categoria Staff:
“Qualsiasi gruppo autorizzato ad accedere a una sottocategoria deve essere autorizzato anche ad accedere alla categoria genitore. I seguenti gruppi hanno accesso a una delle sottocategorie, ma non alla categoria genitore: admins.”
Ma:
i moderatori hanno accesso alla categoria Staff, così come gli amministratori. Quindi dovremmo essere in grado di farlo.
Amministro un altro forum esistente da diversi anni, dove abbiamo sottocategorie sotto Staff riservate solo agli amministratori o solo ai moderatori.
Pareri?
[EDIT: per divertimento, ho fatto uno screenshot dell’etichetta effettiva che appare quando si prova a creare una categoria solo per amministratori:
È piuttosto divertente perché (a) gli amministratori hanno accesso alla sottocategoria Staff, ma anche (b) gli amministratori possono andare ovunque… Quindi, di default, hanno accesso a qualsiasi categoria.
E, naturalmente, non è possibile modificare la sezione sicurezza di Staff per aggiungere specificamente moderatori e amministratori alla categoria principale.]
Devi assicurarti che le sottocategorie che crei siano accessibili solo allo staff. Hai provato a crearne una accessibile a tutti, ma non hai notato le autorizzazioni al momento della creazione, quindi non pensi che ciò sia vero.
È quello che pensavo, da qui il mio messaggio cancellato, ma rileggi il messaggio di errore:
“Qualsiasi gruppo autorizzato ad accedere a una sottocategoria deve essere autorizzato anche ad accedere alla categoria genitore. I seguenti gruppi hanno accesso a una delle sottocategorie, ma non alla categoria genitore: moderatori.”
Quindi ho provato e ho riscontrato lo stesso problema.
Ho cercato di creare una sottocategoria con le impostazioni di sicurezza impostate su “moderatori: possono visualizzare/postare/creare”, ma ho ricevuto lo stesso messaggio di errore, anche se i moderatori dovrebbero essere inclusi in “staff” e le impostazioni di sicurezza della categoria genitore sono impostate su “staff: possono leggere/postare/creare”.
Credo che quanto accade dipenda dal fatto che la sicurezza è impostata per gruppi, non per funzionalità.
Un moderatore appartiene sia al gruppo dello staff che a quello dei moderatori.
Ma se esistesse una categoria dello staff e una sottocategoria dei moderatori, cosa succederebbe a qualcuno che appartiene solo al gruppo dei moderatori? Potrebbe accedere alla sottocategoria ma non alla categoria genitore, e Discourse non lo consente.
In teoria, se volessi rendere una sottocategoria accessibile ai moderatori, dovresti aggiungere “moderatori: può vedere/postare/creare” alle impostazioni di sicurezza della categoria genitore, ma non è possibile sulla sottocategoria predefinita dello staff.
Inoltre, sarebbe inutile, dato che “staff” include sia moderatori che amministratori, e gli amministratori hanno accesso a tutte le categorie.
Sì. Ma è proprio quello che abbiamo fatto. Abbiamo rimosso i permessi per “tutti” ecc… e lasciato solo il gruppo admin o mod come unico in grado di accedere alla sottocategoria. Ma non funziona.
Anche se prima era possibile. E, in base alle regole dei permessi, dovrebbe essere possibile.
Penso di sì.
Ci sono questioni che solo gli admin possono leggere a causa di problemi di privacy e altri motivi. Quindi abbiamo bisogno di sottocategorie riservate solo agli admin.
Le sottocategorie per i mod sono per comodità: riuniscono discussioni su argomenti di moderazione in un’area specifica. Dato che gli admin possono vedere tutto comunque, potremmo etichettarle per i mod ma renderle accessibili allo staff, e funzionerebbe. Risolverebbe metà del problema, anche se, ovviamente, solo aggirando le regole.
Ma l’altra metà non la possiamo risolvere. Modificherò il post originale per riflettere gli admin.
Questo è errato. I moderatori possono accedere alla categoria dello Staff. Quindi, avere una sottocategoria per i moderatori (o per gli amministratori) è (o dovrebbe essere) consentito da Discourse. La regola è che qualsiasi gruppo che può accedere a una sottocategoria deve poter accedere anche alla categoria.
Ma non sarebbe affatto inutile avere una sottocategoria riservata solo agli amministratori, dato che i moderatori non vedono tutto ciò che vedono gli amministratori.
Leggi attentamente il mio messaggio: come è strutturato il sistema, funziona correttamente e l’errore che hai riscontrato è normale. L’accessibilità del forum dipende esclusivamente dai gruppi.
La categoria predefinita per lo staff, creata automaticamente da Discourse, è disponibile solo per il gruppo Staff.
Se desideri creare una sottocategoria per il gruppo Moderatori, non funzionerà, perché la categoria principale è accessibile solo al gruppo Staff, non a quello dei Moderatori.
L’unico motivo per cui i moderatori hanno accesso alla categoria principale è che appartengono anche al gruppo Staff.
Puoi comunque creare una sottocategoria chiamata “moderazione” e impostare i permessi su “lo staff può leggere/scrivere/rispondere”; funzionerà.
In realtà lo sarebbe, e puoi creare una categoria o una sottocategoria accessibile solo al gruppo Amministratori senza alcun problema.
Per chiarezza: penso che questo sia effettivamente il motivo del problema. Inizialmente avevo pensato di menzionarlo come spiegazione, ma ho deciso di pubblicare senza…
Tuttavia, in tal caso, si tratta di uno di quei bug insidiosi in cui le regole che si stabiliscono non riflettono le ragioni che le hanno generate. È molto chiaro che i moderatori fanno parte dello staff, così come gli amministratori, e questa ragione vorrebbe che fossero in grado di avere sottocategorie all’interno di Staff.
E, infatti, un paio di anni fa, era possibile creare sottocategorie in Staff solo per gli amministratori o solo per i moderatori: questo era chiaramente corretto.
Perché sarebbe inutile avere una sottocategoria solo per gli amministratori?
Non nella categoria Staff. Guarda lo screenshot sopra.
Volevo dire che non sarebbe inutile, come hai detto tu.
Sì, hai ragione.
Se vuoi creare queste sottocategorie, dovresti creare una categoria genitore “News Staff” con le impostazioni di sicurezza che consentano la lettura, la pubblicazione e la creazione solo ad Amministratori, Staff e Moderatori, credo.
Perché non creare semplicemente una Nuova Categoria come menzionato? Lo Staff è un gruppo specializzato.
Posso aggiungere utenti a diversi gruppi. Il fatto che alcuni utenti appartengano al Gruppo B e possano anche far parte del Gruppo A non significa che l’accesso del Gruppo A a una Categoria qualifichi automaticamente il Gruppo B ad averne accesso. Le autorizzazioni delle Categorie basate sul Livello di Fiducia, tuttavia, funzionano a un livello minimo.
Non lo so, ma immagino che tu possa probabilmente modificare le autorizzazioni dello Staff per consentire al gruppo dei Moderatori l’accesso diretto.
Non esiste una gerarchia delle autorizzazioni in Discourse. Staff è una raccolta speciale di amministratori e moderatori. Le sottocategorie non possono specificare gruppi che non sono presenti nella categoria genitore, e il gruppo Staff ha ACL fissi. Come indicato nella categoria staff:
Avviso: Questa categoria è predefinita e le impostazioni di sicurezza non possono essere modificate. Se non desideri utilizzare questa categoria, cancellala invece di riutilizzarla.
Non si tratta di un bug, hai semplicemente un caso d’uso che non si adatta alla categoria staff predefinita. Non c’è nulla di sbagliato nel voler fare qualcosa di diverso, ma sarebbe errato insistere sul fatto che, poiché non puoi utilizzare una categoria integrata per uno scopo diverso, ciò costituisca in qualche modo un bug.
È piuttosto evidente che non vuoi utilizzarla così com’è. Nulla ti impedisce di creare una nuova categoria genitore accessibile ad amministratori e moderatori, con sottocategorie separate per ciascuna sotto di essa.
Questo è un bug estremamente minore nel sistema di avviso delle autorizzazioni delle categorie, poiché non riconosce che staff equivale a admins + moderators.
Non vale la pena discutere per 12 post avanti e indietro.
Puoi aggirare il problema aggiungendo esplicitamente admins e moderators come gruppi consentiti alla categoria superiore. Tieni presente che gli amministratori avranno comunque accesso alla sottocategoria moderators.
Sì. Ma i moderatori non avranno accesso alle sottocategorie degli amministratori.
Sì, nel caso generale, ma non è possibile nella categoria Staff, che viene creata automaticamente e dove non è possibile modificare i privilegi, ed è proprio questo il punto della domanda. Poiché (a) la categoria Staff viene popolata automaticamente in ogni installazione, (b) è importante, per motivi di usabilità, limitare il numero di categorie, e (c) la categoria Staff funzionava correttamente in passato, non considero questa una richiesta irragionevole.
Il mio suggerimento è una soluzione semplice. Attualmente, quando viene creata automaticamente la categoria Staff, vengono impostate le seguenti autorizzazioni (e non è possibile modificarle):
staff possono creare/rispondere/vedere
Invece, quando viene creata automaticamente la categoria Staff, Discourse dovrebbe impostare le seguenti autorizzazioni:
staff possono creare/rispondere/vedere
admins possono creare/rispondere/vedere
moderators possono creare/rispondere/vedere
Con questa semplice correzione, questo bug verrebbe risolto, non sarebbe necessario creare categorie aggiuntive e inutili, e la categoria Staff funzionerebbe come in passato.
Penso che i tuoi punti siano invertiti: creare una categoria dedicata allo scopo è di gran lunga più semplice che modificare una categoria integrata, specialmente quando migliaia di altre installazioni operano già con le autorizzazioni esistenti.
In realtà, se leggi attentamente la mia soluzione, ti renderai conto che è retrocompatibile e mantiene le installazioni precedenti funzionanti come prima.
Ma non c’entra nulla con la compatibilità all’indietro. In questo argomento sei l’unico a spingere per un cambiamento. Ciò che proponi richiede comunque tempo di sviluppo, richiede comunque test e richiede comunque manutenzione. Migliaia di installazioni funzionano con la configurazione esistente, il che significa che ci sono anche migliaia di team di amministrazione/moderazione che non hanno problemi con l’impostazione attuale.
Questo argomento è vecchio di mesi. Avresti potuto implementare il modo corretto di farlo già ad aprile; perché dovresti aspettarti che CDCK finanzi un cambiamento al loro software, qualcosa che ha funzionato in questo modo per sette anni, per un singolo sito? Perché chiunque dovrebbe fare qualcosa se non sei disposto a apportare la modifica più semplice alla tua stessa configurazione? La tua riluttanza a seguire le indicazioni non incoraggia l’azione da parte di altri.
Non c’è nulla di speciale nella categoria dello staff; come suggerito mesi fa, potresti creare una diversa categoria con le autorizzazioni appropriate. Problema risolto.
È di gran lunga più semplice per te implementare una piccola modifica nella tua comunità rispetto a qualsiasi cosa di cui sopra.
Non è il modo corretto per farlo, ma l’ho implementato ad aprile. Di solito non aspettiamo che i bug vengano risolti o che le funzionalità vengano implementate per mettere in ordine le nostre cose.
Sì, sì e no. Ho lavorato per molti anni come sviluppatore software e manager, e sono ben consapevole di cosa serve per risolvere un bug. Questa correzione richiederebbe pochi minuti di sviluppo, poche ore di test e non più manutenzione di quella richiesta dalla versione attuale.
Il tuo argomento significa che non c’è assolutamente alcun senso nello sviluppare nulla di nuovo. Ci sono migliaia di team che usano Discourse così com’è: perché spendere anche un’ora in più nello sviluppo? Usiamo la logica quando discutiamo, per favore.
Questa è stata un’assunzione inutilmente scortese, che è ovviamente infondata dato quanto ho scritto sopra.
In realtà, ti sbagli. Per molto tempo ha funzionato in modo diverso e migliore. Ecco un esempio di un sistema Discourse ospitato esistente, vecchio di 4-5 anni, con una categoria Staff nativa che permette sottocategorie per i moderatori:
Il punto non ha nulla a che fare con il mio sistema. Non ho bisogno della modifica per farlo funzionare. Il punto è che ogni singolo sistema Discourse viene fornito con una categoria Staff che è inferiore in termini di funzionalità rispetto a ciò che potrebbe essere e a ciò che era. Se Discourse si prende la briga di creare automaticamente una categoria Staff, perché non progettarla in modo efficace e pulito? Sto facendo una proposta semplice e facile da implementare, che ripristinerà funzionalità utili per chi si occupa di multiple categorie di staff. Il team è libero di considerare la mia proposta o meno.
Attenzione: Questa categoria è pre-seed e le impostazioni di sicurezza non possono essere modificate. Se non desideri utilizzare questa categoria, eliminala invece di riutilizzarla.
Basta ricreare la categoria dello staff e spostare gli argomenti nella nuova?
