Vorrei avere circa 20.000 gruppi nella mia istanza di Discourse, è possibile e ciò influirebbe in qualche modo sulle prestazioni del sito web?
2 Mi Piace
Quanti utenti avrai?
Quale problema risolvono 20.000 gruppi?
2 Mi Piace
Ecco lo scenario. Sto usando Discourse per realizzare una piattaforma di discussione per articoli di ricerca. Ogni articolo è rappresentato con un tag con l’ID dell’articolo. Tutti gli argomenti creati sotto quel tag appaiono nella pagina del tag per quell’articolo.
Il problema è che mi manca la seguente funzionalità:
Ho un processo di approvazione manuale per gli autori degli articoli caricati nel sistema. Voglio dare loro la possibilità di modificare i post che sono taggati con il loro articolo. Ma ho appreso che non è possibile concedere permessi basati sui tag.
Allora, ho avuto l’idea di avere un gruppo per articolo e gli autori di un articolo apparterranno allo stesso gruppo. Ma non sono nemmeno sicuro se questo risolva il mio problema perché non sono sicuro di come dare la possibilità di modificare determinati post.
Apprezzerei sentire se esiste un modo elegante per avere questa funzionalità. Grazie.
3 Mi Piace
Vuoi che l’autore possa modificare i post altrui se è una risposta al suo articolo?
E intendi post e non argomenti?
Sì, se un post è una risposta o correlato al loro articolo è attualmente determinato dal tag.
Ma posso anche creare un gruppo per articolo se ciò può aiutare.
E idealmente, sia i post che gli argomenti dovrebbero essere modificabili.
I gruppi sono molto leggeri, puoi averne molte migliaia senza problemi.
Avere invece 20.000 categorie sarà un problema di prestazioni.
10 Mi Piace
I post non hanno tag, gli argomenti sì.
Non capisco perché vuoi che le persone possano modificare i post altrui. Puoi renderli wiki, ma poi chiunque può modificarli.
O forse vuoi che l’argomento utente sia un wiki in modo che chiunque possa modificarlo.
Non capisco quale sia il modello in cui ha senso cambiare le parole di qualcun altro.
2 Mi Piace
Ho anche iniziato a mettere in discussione i meriti che la modifica apporta dopo aver considerato diversi scenari. Tuttavia, sarebbe bello avere un meccanismo per vedere se una persona che risponde è l’autore dell’articolo a cui è correlato l’argomento e penso che non sia ancora possibile con i gruppi.
Più esplicitamente: Diciamo che un utente ha creato un post taggando l’articolo con id 5. Se l’autore dell’articolo 5 risponde a quell’argomento: La funzionalità ideale sarebbe indicare in qualche modo (può essere un flair, un titolo, un piccolo testo predefinito in cima al post) che l’utente che risponde è l’autore dell’articolo in discussione.
Se ogni paper è un argomento e assegni l’OP dell’argomento all’autore, è banale creare una regola CSS per aggiungere una differenziazione visiva alle risposte dell’OP sui loro ulteriori commenti.
1 Mi Piace
Perché non avere semplicemente un argomento per ogni articolo? In questo modo non ci sarebbe confusione. Non avresti bisogno di tag o gruppi.
Inoltre, sembra che tu stia confondendo il senso di argomento di Discourse (una raccolta di post) con un post (un singolo messaggio di una singola persona che risiede in un argomento).
Ma ora @falco mi ha anticipato…
1 Mi Piace
@pfaffman @falco Tecnicamente, ogni paper è un tag. Il motivo è che un argomento non è sufficiente per avere tutte le discussioni o le domande su un paper. Ci sono molti aspetti diversi da discutere e la motivazione principale di questo forum è avere un’unica fonte di tutte le discussioni avvenute attorno a un paper. Pertanto, ogni paper è un tag e tutti gli argomenti creati sotto il tag di un paper possono essere visti dalla pagina /tag/:paper_id.
È possibile fare il trucco CSS in questo scenario? Posso creare un database esterno che definisca la relazione tra i tag e i loro rispettivi “utenti autori”, se necessario.
1 Mi Piace
Sì, potresti avere un file CSS che verrebbe generato automaticamente dall’analisi di detto database.
Potresti anche fare tutto questo in Discourse utilizzando un plugin personalizzato. Porterebbe un campo aggiuntivo nel serializzatore dell’argomento per i post in cui l’autore del post corrisponde, che può quindi essere sfruttato dall’applicazione front-end.
1 Mi Piace
Capisco, sono abbastanza nuovo ai plugin ma cercherò di vedere cosa si può fare. Grazie mille per il consiglio!
2 Mi Piace
Sentiti libero di aprire argomenti su Dev quando rimani bloccato.
1 Mi Piace
Quindi capisci che gli argomenti hanno tag, non i post. Penso che tu stia usando la parola “post” quando intendi “argomento”.
Non credo che tu abbia risposto a questo. Se non vuoi che le persone modifichino i post di altre persone, non credo che tu abbia alcun problema. Non riesco a immaginare perché vorresti che le persone modificassero i post di altre persone, ma se lo fai, renderli un wiki potrebbe essere la soluzione.
Taggare argomenti che riguardano un particolare articolo con un tag dell’articolo (come un DOI, ma immagino che potrebbe non esserci un DOI in questa fase della vita dell’articolo) è un’ottima idea e puoi farlo subito con l’API. Inoltre, gli utenti che potrebbero modificare l’argomento (trust_level 3 e il proprietario dell’argomento) possono aggiungere il tag; altri potrebbero segnalarlo e chiedere che venga taggato (ma chi ha iniziato l’argomento non sa che riguarda l’articolo?).
Non mi è chiaro per cosa ti serva un plugin a questo punto.
Potresti dire qualcosa su dove si manifesterebbero i problemi di prestazioni? Cioè, si tratta di pagine specifiche o di un problema generale? Se ogni categoria è collegata a uno o due gruppi e l’utente medio ha accesso solo a 10-20 categorie in totale, è ancora un problema avere 20.000 categorie?
Per il mio caso d’uso (ipotetico), si tratta di consentire la discussione di argomenti pubblici tramite messaggi privati di gruppo. Questo approccio potrebbe essere utilizzato in alcuni modi diversi nel tentativo di generare discussioni pubbliche produttive su argomenti polarizzanti. Essenzialmente, le discussioni potrebbero essere gamificate chiedendo alle persone di unirsi a squadre (gruppi) relative a un argomento specifico e quindi seguire un insieme di regole per rispondere all’argomento pubblico come squadra.
Sono preparato ad affrontare i problemi dell’interfaccia utente che migliaia di gruppi potrebbero creare per lo staff del sito. Mi rendo conto che questo è un caso d’uso inaspettato per i gruppi di Discourse, quindi lo sto pubblicando qui nel caso ci siano problemi di prestazioni evidenti che mi sfuggono.
1 Mi Piace
Beh, ha più senso di quanto immaginassi. 
Penso che ci sia una funzionalità di gruppo creato dall’utente in fase di sviluppo, ma sospetto che sia ancora lontana.
1 Mi Piace
Sarebbe fantastico, ma per ora può essere fatto con l’API.
1 Mi Piace
Oooh. Sto andando fuori tema qui, ma potresti usare una di quelle cose API che ricevono un webhook per ogni nuovo argomento e poi creano un gruppo per esso. Nessun plugin richiesto. Non so perché non avessi pensato prima di avere Discourse su entrambi i lati di uno di quei servizi.
E GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy fully‑managed AI agents and workflows è arrivato sulla mia scrivania oggi. Sembra che potresti farlo lavorare invece di pagare uno di quei servizi. Dubito che abbia il supporto Discourse pronto all’uso, ma dovrebbe essere abbastanza facile da farlo funzionare.
1 Mi Piace