Questo è come un argomento Feature - Dev, non sono sicuro in quale dovrebbe essere.
C’è un modo per modificare le impostazioni del sito in un plugin? Sono sicuro al 99% che non ci sia, ma vorrei solo confermarlo.
Se non c’è, posso proporre un suggerimento per non renderla immutabile? O forse, avere qualche API o un modo per ‘sbloccare’ la proprietà immutabile di SiteSettings, forse?
Un possibile caso d’uso che sto valutando è quello di includere un elenco di categorie protette in un’impostazione in modo che sia più facile per l’amministratore includerle/escluderle.
Vuoi solo cambiare il valore delle impostazioni del sito? Fai semplicemente SiteSetting.whatever='new value. O vuoi cambiare qualcosa riguardo ad esse?
Non vuoi semplicemente aggiungere un’impostazione per quello? Aggiungila semplicemente a config/settings.yml? Qualcosa come
[quote=“NateDhaliwal, post:1, topic:389676”]Un possibile caso d’uso che sto valutando è quello di includere un elenco di categorie protette in un’impostazione in modo che sia più facile per l’amministratore includerle/escluderle.
[/quote]
Cominciamo da qui e lavoriamo dall’esterno verso l’interno.
Puoi prima descrivere il caso d’uso dal punto di vista della community? Cosa stanno cercando di realizzare e cosa rende difficile farlo ora? Quale funzionalità immagini che risolverebbe la loro esigenza in modo più efficace (indipendentemente da come viene implementata)?
Quindi, possiamo procedere da lì per determinare se è meglio farlo in un plugin o come funzionalità principale.
Quindi, possiamo procedere da lì per discutere suggerimenti su come implementarlo.
Ho erroneamente supposto che poiché le impostazioni sono immutabili nei TC, lo siano anche nei plugin in Ruby. Ci proverò.
Sarebbe bello renderle modificabili nei TC. Il mio caso d’uso (per il quale sto usando un plugin al momento) è prendere tutti i topic e i post in tutte le categorie per impostazione predefinita ed eseguire alcune operazioni su di essi, ma non vorrei includere le categorie protette (come un’impostazione excluded_categories).
Tuttavia, se fosse possibile aggiungere le categorie protette all’impostazione e poi accedervi in seguito, sarebbe più facile. In questo modo, gli amministratori possono includere alcune categorie protette se lo desiderano rimuovendole dall’impostazione.
Con l’idea di @pfaffman, probabilmente si può fare, ma non nei TC.
Il problema è che non conosco in anticipo le categorie protette.
Se si è connessi come amministratore, un componente tema potrebbe modificare le siteSettings tramite l’API.
Allora imposta semplicemente un’impostazione del componente tema e aggiungi quelle categorie? Non ti riferisci a qualche impostazione del sito protected_categories a cui non sto pensando, vero? Quindi qualcosa del genere?
Mi piacerebbe saperne di più. Penso che mi aiuterebbe a contestualizzare meglio questa richiesta.
Sei disposto a condividere di più sulla tua community?
Sei l’utente principale di questa funzionalità o ci sono altri membri del tuo team che ne hanno bisogno? Hai documentazione rivolta agli utenti per il flusso di lavoro che dipende da questa funzionalità? In tal caso, come appare? In caso contrario, puoi descrivere brevemente come potrebbe apparire?
Sto sviluppando un plugin che prende argomenti e post e li pubblica su GitHub come file Markdown (come un archivio).
Tuttavia, non vorrei includere le categorie private (penso che ora questo sia il termine corretto?) in questo, poiché sono “private”.
Pertanto, sto cercando un modo per precompilare un’impostazione con l’elenco delle categorie private, che non può essere definita all’interno del parametro default, poiché non saprei in anticipo quali siano le categorie private.
Nel caso in cui ciò possa essere fatto modificando direttamente SiteSetting in Ruby, è possibile fare lo stesso con le settings di un Componente Tema? Sono abbastanza sicuro che quest’ultimo sia immutabile. C’è un modo per modificarlo in un Componente Tema?
Non si tratta davvero della community. Sto tentando di fare qualcosa di simile a questo (con anche un lavoro di riempimento) a modo mio. Questo salva ogni discussione e post come file Markdown in un repository.
Non ho ancora capito cosa intendi per privato. Significa che vuoi solo le categorie visibili a tutti, o agli utenti anonimi? O hai qualche altra definizione?
Se le vuoi, allora il tuo plugin può ottenere solo quelle, magari tramite una ricerca a cui passi un utente (o forse chiamando un guardiano), o semplicemente controllando i permessi.
Oppure, se privato è qualcosa che è un’opinione, puoi aggiungere un’impostazione.
E probabilmente vuoi farlo in un job che viene eseguito quotidianamente o altro?
Se stai caricando cose su github, penserei che vorresti che discourse lo facesse e basta piuttosto che pasticciare con il tuo browser che invia dati a discourse? Non vedo come o perché lo faresti con un componente tema.
Intendo categorie come Staff, e altre limitate dai gruppi. Penso sia possibile con un plugin, ma immagino che le impostazioni di TC non siano modificabili allora?
Ancora una volta, penso che affrontare questo il più possibile dalla prospettiva del risultato finale su cui stai lavorando, più facile sarà dare consigli.
Quindi grazie per aver condiviso questo link:
Forse possiamo usarlo come punto di partenza per chiarire ulteriormente la specifica funzionale che hai implicitamente definito finora.
Il modo in cui lo sto capendo ora è che vuoi:
creare un archivio html statico di un sito Discourse
mantenerlo aggiornato man mano che vengono creati nuovi contenuti
escludere determinate categorie
E il design che stai attualmente esplorando è:
creare un plugin che:
permetta agli amministratori di:
configurare esplicitamente quali categorie escludere
configurare un URL git per memorizzare i contenuti statici
esegua un lavoro in background periodicamente che:
crei file markdown per argomenti e post
li memorizzi in una struttura di file/directory in un repository git
li carichi su GitHub
gli utenti finali possano vedere il contenuto su GitHub come html
Sto interpretando correttamente che ti riferisci al metodo Category.where(...) per ottenere queste categorie “private”? Ma se l’amministratore volesse includerne (alcune) - dovrei avere un’impostazione include categories che annulli le categorie “private” definite nel codice? Non sarebbe controproducente?
Non lo capisco ancora. Sì, è possibile aggiungere quelle impostazioni in un SiteSetting e sì, il plugin potrebbe leggere tale impostazione e persino modificarla. Ma perché dovrebbe aver bisogno di cambiare l’impostazione dato lo scenario sopra?
Supponiamo di avere 5 categorie: A, B, C, D ed E. Ora diciamo che B e C sono disponibili solo per alcuni gruppi. Per evitare che gli argomenti privati qui vengano condivisi quando caricati nel repository, B e C vengono aggiunti all’impostazione excluded_categories, insieme ad altri come ad esempio Staff.
Ora supponiamo che l’amministratore del sito sia d’accordo che gli argomenti di B vengano condivisi, può procedere e rimuovere B dall’impostazione, lasciando comunque C.
Quindi l’impostazione excluded_categories dovrebbe essere modificata inizialmente per aggiungere le categorie “private” B e C. Non sono sicuro che abbia senso?
Sebbene ciò sia perfettamente possibile dal punto di vista tecnico, penso che l’approccio sarebbe troppo complicato, soprattutto perché “all’inizio” è difficile da definire/rilevare, e si vuole evitare che il plugin continui ad aggiungere B dopo che l’amministratore del sito l’ha rimosso. Inoltre, quando viene aggiunta una nuova categoria privata, il plugin dovrebbe aggiungerla, ma dovrebbe essere in grado di vedere la differenza tra una nuova categoria (aggiungi) e una categoria che era stata precedentemente rimossa dall’amministratore (non riaggiungere).
Opterei per un’impostazione include_private_categories che inizia vuota, e il plugin elaborerebbe semplicemente tutte le categorie pubbliche E le categorie in include_private_categories. Questo ti darà molti meno mal di testa.
Un’altra alternativa di progettazione che potrei immaginare qui è avere due repository separati: uno per i contenuti pubblici e uno per i contenuti privati.
Il repository dei contenuti privati potrebbe essere mantenuto privato (potresti determinare chi vi ha accesso indipendentemente).