Scusa, è un vecchio post, ma perché non imposti il tuo tema come repository su GitHub? Concedi al tuo team di design e UX i permessi per accedere e aggiornare il tema su GitHub.
In Discourse ora puoi configurare i temi per l’aggiornamento automatico al momento della ricostruzione.
I tuoi amministratori dovranno solo ricostruire per apportare le modifiche effettuate dal team di design e UX, e quest’ultimo non avrà affatto bisogno di accesso all’amministrazione.
Solo una breve nota:
Quando si gestiscono questioni relative al controllo degli accessi, in generale, questi controlli RBAC dovrebbero essere eseguiti lato server.
Il codice RBAC in Javascript lato client può essere manipolato dal client.
Ciò significa che, quando si definiscono le autorizzazioni RBAC fondamentali per il personale, gli amministratori e i moderatori, questo dovrebbe essere fatto (in linea di massima) in Rails, non in Javascript.
A proposito, è così che Discourse gestisce ora l’RBAC, utilizzando quello che Discourse chiama “guardian”, una classe Ruby chiamata class Guardian, qui:
Se uno sviluppatore intende aggiungere controlli RBAC nel codice Javascript chiamando l’API di Discourse, tenga presente che questo codice può essere compromesso perché il codice eseguito nel browser può essere manipolato.
Il mio consiglio è di assicurarsi che tutto il codice RBAC fondamentale venga eseguito lato server e di non cercare di accorciare il percorso tramite Javascript lato client.
Esiste anche il livello di fiducia 4 e i moderatori di categoria, in Discourse 2.5 e versioni successive.
Anch’io ho un caso d’uso simile: gestisco una piccola comunità no-profit in cui uno dei nostri utenti si occupa della manutenzione dei temi e del design.
Non desidero concedere a nessuno, tranne a me e al mio co-proprietario, l’accesso ai dati privati degli utenti (indirizzi e-mail, ecc.), ma ho 4 moderatori.
Per permettere al designer di lavorare, ho dovuto creare un sito copia senza contenuti, dove lui è amministratore, e poi copio manualmente temi e componenti. Tuttavia, questa soluzione non è ideale, poiché alcune modifiche richiedono la presenza di contenuti per essere verificate.
Perché non aggiungere del contenuto al sito di staging / testing? Sarebbe il consiglio tipico.
Quindi, lascia che lo sviluppatore lavori sul sito di staging e spinga i temi su GitHub. Tuttavia, dovrai comunque eseguire tu stesso l’aggiornamento. Potresti riuscire a farlo tramite l’API e in qualche modo permettere allo sviluppatore di attivarlo.
Sto lavorando a uno strumento che potrebbe essere d’aiuto in questo senso.
Abbiamo esattamente questa esigenza anche noi, qualcuno per caso ha risolto?
Non so se questo sia utile in questa situazione, ma se hai solo bisogno di alcuni contenuti, c’è il task rake populate:
Grazie, purtroppo al momento non è molto utile.
Se non ti fidi del designer a vedere i tuoi dati, quale soluzione immagineresti?
Potresti dargli solo una chiave API che gli permetterebbe di usare il discourse_cli per inviare il tema lì e poi disattivarla quando ha finito, forse?
Non c’è assolutamente alcun motivo per cui un designer debba avere accesso a 100.000 utenti lol. Inoltre, sarebbe contro le regole del GDPR. È possibile fornire una chiave CLI solo per gli aggiornamenti del tema?
Mi scusi! Penso che abbia ragione.
Ora, a differenza di quando è stato creato questo argomento (che apparentemente era dove si trovava il mio cervello quando ho scritto la mia risposta), abbiamo chiavi API granulari. Non dovrebbe essere troppo difficile aggiungere un nuovo ambito solo per la gestione dei temi.
Potrebbe valere la pena creare un nuovo argomento in Feature chiedendo un ambito di chiave API per sviluppatori di temi. Sembra una buona idea.
No, non lo è. Può essere contro le regole di quel sito, ma quelle possono e dovrebbero cambiare.
Sarebbe bello se @AV_C potesse pubblicare un riferimento a questo requisito. Sebbene possa apprezzare molto il motivo per cui un cliente vorrebbe limitare l’accesso alla base utenti e persino alle categorie private per una serie di ragioni. L’amministratore completo può accedere alle email di registrazione dei membri e le categorie private potrebbero contenere altri contenuti sensibili a seconda del caso d’uso del cliente.
Penso che @pfaffman abbia una buona idea per garantire che questo tipo di lacuna possa essere coperta tramite un’API amministrativa ristretta. Una volta completato il lavoro di progettazione, la chiave può essere revocata finché non sarà necessaria.
Ciò si adatterebbe anche all’idea di Jay di non mostrare un utente come amministratore nella pagina Informazioni.