Ciao!
Vorrei modificare le autorizzazioni dei gruppi di utenti, ad esempio:
Gruppo Amministratori: tutte le autorizzazioni
Co-Amministratore: può fare tutto tranne aprire alcune sezioni nel pannello di amministrazione
Come posso farlo? Grazie!
Non è possibile di default, dato che gli amministratori hanno accesso illimitato a tutte le sezioni del forum. A seconda di quali permessi desideri revocare, potrebbe essere utile degradarli a moderatore?
I moderatori non possono creare categorie e io vorrei poterlo fare
I moderatori possono creare categorie se abiliti l’impostazione moderators_create_categories nella tua amministrazione di Discourse.
Dove posso trovarlo? Ho esaminato tutte le categorie nel pannello di amministrazione e non ho visto nulla che potessi assegnare ai moderatori.
*Esiste qualcosa come moderators_create_themes?
Vai su Amministrazione > Impostazioni
Quindi cerca la parola chiave moderators_create_categories
Il tuo Discourse è aggiornato?
Ciò che stai chiedendo è: “Esiste qualcosa come ‘i moderatori possono far crashare l’intero sito creando un tema rotto’?”. Sono quasi certo che la risposta sarà “No”.
Potresti installare un tema remoto ospitato su GitHub che un moderatore potrebbe modificare, ma un amministratore dovrebbe comunque integrare le modifiche.
Non sai chi smanierà con i temi, come puoi fare quella affermazione?
Ho fatto questa domanda perché non ci sono gruppi con regole personalizzate come indicato sopra.
Il mio punto è che se ti fidi abbastanza di qualcuno da permettergli di cambiare i temi, allora puoi assegnargli i privilegi di amministratore.
Se desideri consentire a utenti non amministratori di modificare i temi o alterare ciò che un moderatore può fare, avrai bisogno di un plugin personalizzato.
Non nel mio scenario attuale. Abbiamo team UX e Design che sono responsabili solo di quell’area, quindi sarebbe necessario solo l’accesso ai temi.
Abbiamo anche noi lo stesso caso d’uso. Abbiamo appaltatori esterni (web designer) a cui vogliamo concedere l’accesso a questa funzionalità. Un amministratore completo avrebbe accesso a tutto, comprese le discussioni private di gestione, il che non è desiderabile.
Sarebbe utile disporre di un flusso di lavoro che permetta ai web designer di inviare o provare modifiche senza richiedere l’accesso completo di amministratore.
Ciao @Joaquin_Menchacha,
Grazie per il tuo messaggio e per il promemoria su questo argomento.
Anche noi auspichiamo (e pianifichiamo) di affinare alcuni dei controlli amministrativi in futuro.
Ad esempio, siamo interessati a un plugin (in un prossimo futuro) che verrà configurato tramite variabili nel file di container yml e che limiterà determinate azioni amministrative (come il download del backup completo del sito) solo a specifici utenti (userids).
Questa idea di plugin è “nella mia lista di priorità” e, non appena avrò l’opportunità, la esaminerò più approfonditamente. Al momento, non ho ancora compiuto il primo passo, ovvero analizzare il codice e valutare la fattibilità di questa idea.
Qualcuno ha trovato una soluzione qui?
Ho lo stesso caso d’uso: voglio concedere l’accesso al tema e agli annunci interni ad alcuni membri del mio staff.
La soluzione più semplice è fidarsi delle persone e nominarle amministratori o moderatori. Se non ti fidi di loro per avere il controllo completo, ma desideri che abbiano un accesso aggiuntivo, allora avrai bisogno di un plugin.
Non è che non mi fidi di loro. Ma quando si tratta del nostro modello di minaccia, crea una superficie di attacco aggiuntiva. E se l’utente specifico venisse compromesso a causa della mancanza di sicurezza dal suo lato? Ci sono molte variabili in gioco.
Allora esploreremo l’opzione del plugin.
Concordo: Discourse necessita di controlli aggiuntivi per la personalizzazione. Come già menzionato da altri, si potrebbe assumere personale esterno per utilizzare funzioni di livello superiore, proteggendo al contempo le informazioni dei membri.
La moderazione di gruppo è discreta, ma a volte si potrebbero voler accedere a funzioni più avanzate di un moderatore completo, senza però averne tutte le funzionalità.
Un plugin potrebbe effettivamente essere utile. Ma proprio come il plugin Merge User è stato integrato nel core, anche le funzionalità di moderazione/amministrazione più avanzate e personalizzabili dovrebbero esserlo, per consentire la creazione di ulteriori tipi di personale.
Concordo con gli altri: il modello di controllo degli accessi sarebbe migliorato con un ulteriore livello di granularità RBAC (controllo degli accessi basato sui ruoli) che specifichi cosa possono accedere gli utenti staff e admin (per certe funzioni, non per tutte).
Ad esempio, un sito potrebbe voler aggiungere più amministratori, ma preferisce concedere un insieme più ristretto di privilegi RBAC agli amministratori; ad esempio, concedere o meno la possibilità di scaricare l’intero backup del sito o di accedere a determinati file di log delle azioni dello staff. Inoltre, un sito potrebbe voler garantire che alcuni membri dello staff non abbiano i permessi RBAC per visualizzare le azioni degli amministratori o degli sviluppatori, o solo determinate azioni considerate più “private”.
Tutti gli esperti di cybersecurity vengono istruiti (e lo sanno per esperienza diretta) che la minaccia più grande per qualsiasi organizzazione è l’“insoddisfatto interno” e non gli hacker o gli attaccanti esterni. Non c’è alcun dubbio su questo rischio di base della sicurezza IT, ed è una conoscenza consolidata per i professionisti della sicurezza IT formati o esperti. Pertanto, liquidare la minaccia interna con frasi come “basta fidarsi dell’amministratore” o “devi fidarti dello staff” non è una soluzione tecnica per i professionisti IT. Anche lo staff più affidabile, leale per molti anni, può iniziare ad affrontare problemi personali che potrebbero trasformarlo in un “membro dello staff insoddisfatto”. Inoltre, sono proprio gli staff più privilegiati a commettere la maggior parte degli errori; e sappiamo tutti che, in generale, gli errori benintenzionati di staff o amministratori causano più tempi di inattività di qualsiasi hacker.
Qualche tempo fa, ho considerato di modificare la classe Guardian di Discourse per il nostro sito, ma dopo un’ulteriore analisi di quella classe non mi è risultato ovvio che ci fosse una “soluzione rapida” che mi permettesse di scrivere una quantità minima di codice di monkey patch per migliorare l’RBAC di Discourse. Essendo per natura pigro e preferendo creare soluzioni semplici quando possibile, ho rimandato l’idea e mi sono dedicato ad altri progetti “ben retribuiti per i clienti”.
Successivamente, ho considerato di scendere di un livello nel codice e trasferire alcune delle funzioni staff e admin a developer, ma questo approccio richiedeva troppi monkey patch, cosa che ritenevo non fosse una buona idea al momento. Dopo tutto, se possiamo ottenere qualcosa con un solo monkey patch invece di dieci, è ovvio che un patch è meglio.
Non ho ancora avuto il tempo o un “requisito urgente” per approfondire questa parte del core di Discourse per determinare se esiste un potenziamento “semplice” sotto forma di plugin RBAC che possa scrivere tramite un plugin “relativamente semplice”.
Onestamente, penso che il problema sia che non sono ancora un super rubyista e, per la maggior parte, mi considero più un “aspirante” programmatore Ruby, LOL. Sono sicuro che esista, molto probabilmente, una semplice soluzione di plugin RBAC là fuori, ma personalmente non l’ho ancora trovata e forse una persona Ruby molto più esperta può guardare rapidamente il codice e vedere come affrontare la questione.
La mia idea sarebbe quella di avere alcune nuove impostazioni booleane del sito che limitino o concedano specifici permessi RBAC in base al ruolo, e poi aggiungere questi booleani alla parte appropriata del codice tramite un monkey patch nel plugin. Tuttavia, come ho già detto, preferirei patchare un solo file, non “molti”, in modo che sia pulito, semplice e facile da mantenere.
Quando avrò tempo, approfondirò questo potenziamento RBAC, poiché è sicuramente interessante.
Ciao @jrgong
Non è difficile farlo tramite un plugin, come probabilmente sai bene.
In sostanza, potresti creare un elenco di membri dello staff (tramite email, nome utente, ecc.) come impostazione globale, in modo simile a come Discourse definisce gli sviluppatori in base all’indirizzo email.
Poi, potresti utilizzare quella GlobalSetting in alcune patch per abilitare i due casi d’uso che ti interessano.
Il primo dei tuoi casi d’uso: personalizzare i temi come membro dello staff, è relativamente semplice da implementare tramite monkey patching del core, penso.
Per il secondo caso d’uso, con poco lavoro, potresti fare un fork di questo plugin e ridisegnare il vincolo di accesso alla rotta in questo plugin (e eventuali altre modifiche necessarie):
Poiché il vincolo per il plugin degli annunci è integrato nel plugin stesso, è una buona idea modificare effettivamente quel codice per consentire ai tuoi membri dello staff “autorizzati” di accedere alle parti del plugin che desideri, basandoti sul tuo stesso RBAC.
In altre parole, entrambi i requisiti che desideri sono fattibili, se sei disposto a scrivere il codice; oppure, naturalmente, puoi chiedere a uno dei professionisti esperti nello sviluppo di plugin Discourse di aiutarti in Marketplace.
Grazie @neounix, apprezzo molto il tuo contributo! Farò in modo che uno sviluppatore lo realizzi.
edit: Non c’è un altro modo se non fare un fork del plugin?
E per quanto riguarda l’accesso al plugin Babble Chat? Anche quello richiederebbe un fork?
Stiamo parlando di software.
Ci sono sempre molti modi per fare le cose.
Ti ho fornito i miei consigli.
