@dax È ancora vero nel 2020 che non è possibile limitare i post in un argomento agli utenti del gruppo dell’autore?
Vogliamo utilizzare Discourse con il nostro sistema di apprendimento online… vogliamo avere un insieme di circa sette argomenti attraverso cui si spostano diverse coorti (gruppi) di utenti, in modo che possano vedere solo i post all’interno del proprio gruppo. Preferiremmo avere un unico insieme di argomenti piuttosto che creare gli stessi argomenti ripetutamente per ogni nuova coorte.
Forse nel frattempo è arrivata un’altra nuova funzionalità che rende possibile questo? Grazie per qualsiasi riflessione.
Scusa, la tua domanda non è chiara e sembra non pertinente.
Puoi creare categorie e proteggerle utilizzando i gruppi.
Ciò che @HappyGezim sta chiedendo è una funzionalità personalizzata di “sussurro” all’interno di un argomento, ma questa non è prevista nella nostra roadmap.
@sam Grazie per la tua rapida risposta! Cercherò di chiarire il nostro scenario esatto:
Abbiamo configurato quattro categorie, una per ciascuno dei quattro corsi che offriamo.
In ogni categoria (corso) abbiamo circa 5-10 argomenti, uno per ogni “Lezione” del corso… più alcuni extra come “Domande Tecniche”, “Presentati” ecc. Man mano che ogni Lezione arriva, gli studenti sono invitati a contribuire all’argomento correlato.
Avremo molte coorti di studenti che seguiranno questi corsi e vogliamo limitare i post in un argomento al loro “gruppo” di coorte. In questo modo manteniamo le stesse categorie e gli stessi argomenti statici e modifichiamo semplicemente le proprietà degli utenti per assegnarli a gruppi diversi, che potremmo creare (?) tramite l’API e assegnare dinamicamente agli studenti (?)
Quindi questo è il contesto che mi ha portato a concentrarmi sulla domanda principale: “All’interno di un argomento specifico, posso creare un messaggio visibile solo agli utenti che appartengono a un gruppo specifico?”
Daniel, anch’io gestisco un corso tramite Discourse. Uso una categoria e una sottocategoria che permettono di limitare l’accesso nel modo più semplice.
Categoria: Corso Acme
Sottocategoria: 2020-05 - Conversazioni del corso
Gli studenti di un determinato gruppo vedono solo una sottocategoria.
@waffleslop Fantastico. Grazie. Crei quelle sottocategorie manualmente ogni volta che hai una nuova coorte? (o forse tramite API?)
Speravo di evitarlo perché per ogni coorte dovrò impostare le stesse 5-10 nuove discussioni in una sottocategoria. Potremmo avere diverse coorti simultanee che seguono lo stesso corso, il che significa che dovrei essere creativo con la denominazione. Quindi, basandomi sul tuo esempio… 2020-05-cohort-A Discussioni del corso
… oppure forse esiste un modo per creare sottocategorie di sottocategorie di sottocategorie, ma non ho ancora approfondito quell’aspetto.
Quando arriva una nuova coorte, crea una nuova categoria per la coorte. Chiedi agli studenti di cliccare sull’icona e poi su “nuovo argomento” per creare un nuovo argomento per quell’assegnazione nella categoria della coorte. Ho fatto sì che etichettassero ogni assegnazione con un tag di assegnazione per rendere più facile tracciare se e quando le persone avevano completato l’assegnazione (e ho creato dei distintivi che venivano assegnati se “mi piaceva” il loro argomento; ho persino scritto uno script per farlo per tutti loro, generare un file CSV e caricarlo sul LMS universitario che non volevo utilizzare).
La mia idea di partenza era utilizzare le sottocategorie per raggruppare i cohort sotto un corso, ma ho notato questo messaggio nell’interfaccia mentre stavo creando una sottocategoria:
Ho ragione a pensare che questo significhi che non è possibile utilizzare le sottocategorie per raggruppare i cohort sotto un corso e poi usare i permessi dei gruppi per limitarli a quella sottocategoria? @waffleslop sei riuscito a limitare l’accesso per sottocategoria con il tuo approccio? Forse ho interpretato male quel messaggio nell’interfaccia.
Se non è possibile limitare una sottocategoria a un gruppo, @pfaffman penso che il tuo approccio (grazie per la spiegazione), ovvero creare una nuova categoria per ogni cohort, sia probabilmente l’unica opzione.
Dato che i nostri 10 o più argomenti in ogni corso sono piuttosto fissi, con nomi e numerazioni specifici, ecc., sto pensando di crearli tramite API ogni volta che viene creato un nuovo cohort nel nostro sistema. Quindi, per ogni nuovo cohort che creiamo nel nostro LMS, utilizzerò l’API per:
creare una nuova categoria in Discourse per quel cohort
creare un nuovo gruppo in Discourse con accesso a quella categoria
creare i corretti 10 o più argomenti nella nuova categoria.
ogni volta che uno studente viene aggiunto a un cohort nel nostro LMS, aggiungerlo al gruppo corretto in Discourse (e rimuoverlo se se ne va)
Hai mai provato questo approccio invece di affidarti allo studente per creare l’argomento da solo? Mi chiedo cosa succederebbe se diversi studenti creassero argomenti con nomi leggermente diversi per lo stesso compito del corso.
Non sono sicuro di aver capito il tuo suggerimento di utilizzare “categorie di sola lettura” per un aspetto di questo problema.
Grazie mille per il tempo dedicato a scrivere le tue riflessioni!
Aha. Grazie @waffleslop. Ok, quindi stai dicendo che puoi limitare la sottocategoria al gruppo e quindi impedire l’accesso ad altre sottocategorie. Ho frainteso quel messaggio dell’interfaccia utente che ho copiato sopra.
Pertanto, il nostro approccio sarà probabilmente quello di utilizzare l’API per:
creare una nuova sottocategoria in Discourse per ogni coorte
creare un nuovo gruppo in Discourse con accesso a quella sottocategoria (nonché alla categoria genitore, come indicato dal messaggio dell’interfaccia utente sopra)
creare i circa 10 argomenti corretti nella nuova sottocategoria
ogni volta che uno studente viene aggiunto a una coorte nel nostro LMS, aggiungerlo al gruppo corretto in Discourse (e rimuoverlo se se ne va)
Sono quasi certo che il genitore possa essere in sola lettura mentre le sottocategorie sono ristrette a un solo gruppo.
È possibile, ma in questo modo devi creare (e mantenere, a meno che non le imposti perfettamente al primo tentativo) le categorie in sola lettura con le istruzioni una sola volta, e quando crei una coorte, devi creare solo una sottocategoria.
Penso che sia per questo motivo che ho utilizzato i tag. Assegneranno il tag del compito all’argomento, così l’argomento potrà avere un nome descrittivo, ma non ci saranno problemi anche se ne scelgono uno poco appropriato.
Per chiunque segua l’approccio descritto sopra, ovvero utilizzando sottocategorie per ogni ‘coorte’ del corso e ripetendo i temi di discussione in ciascuna, assicurarsi di abilitare l’impostazione “consenti titoli di argomento duplicati”, altrimenti Discourse non consentirà di ripetere gli stessi argomenti in ogni sottocategoria.
Questa è una delle ragioni per cui mi piace la mia soluzione di avere una singola categoria di sola lettura contenente i contenuti, e di far discutere gli studenti di tali contenuti creando nuovi argomenti nella categoria specifica del cohort.
Ciao @Daniel_McQuillen. Ero curioso di sapere come è andata il tuo corso. Sto valutando di gestire tre corsi, ognuno con più cohort, e sono interessato alla tua esperienza finora.
Inoltre, stai scadendo alcuni dei tuoi corsi o l’accesso alle discussioni?
Siamo attualmente in fase beta, ma l’integrazione con Discourse sta procedendo bene. Stiamo utilizzando l’integrazione SSO per obbligare l’accesso al nostro sito. Funziona senza problemi, anche se ho notato quanto segue:
Discourse non accetta nomi utente contenenti il simbolo “@”… tronca il nome utente alla sola parte precedente la “@”. Questo può causare problemi se in seguito si chiamano le API di Discourse usando quel nome utente come argomento. Discourse non riconoscerà un nome utente come someone@example.com perché in Discourse il nome utente di quell’utente viene memorizzato come “someone”… un modo semplice per evitare questo problema è non permettere l’uso del simbolo “@” nei propri nomi utente!
Quando qualcuno si registra sul proprio sito, è necessario chiamare esplicitamente le API di Discourse per sincronizzare l’utente SSO, poiché potresti voler eseguire alcune operazioni su quell’utente (ad esempio, aggiungerlo a un gruppo di Discourse) prima che visiti per la prima volta il sito di Discourse (cosa che sincronizzerebbe automaticamente l’SSO). Ho un sito basato su Django, quindi sto utilizzando la libreria pydiscourse, che offre un metodo sync_sso che rende tutto molto semplice (pydiscourse · PyPI)
Sì, disattiveremo alcuni dei nostri corsi; in tal caso, il server chiamerà le API di Discourse per rimuovere l’utente dal gruppo generale relativo a quel corso, nonché dal gruppo dedicato alla sua coorte all’interno di tale corso.
Ho creato delle tabelle nel mio sito Django che tengono traccia di questi gruppi “corso” e dei vari gruppi “coorte” all’interno di ciascun corso. Utilizzo quindi queste informazioni quando aggiungo o rimuovo studenti, ecc.:
e poi su “nuovo argomento” per creare un nuovo argomento per quell’assegnazione nella categoria della coorte. Ho fatto sì che etichettassero ogni assegnazione con un tag di assegnazione per rendere più facile tracciare se e quando le persone avevano completato l’assegnazione (e ho creato dei distintivi che venivano assegnati se “mi piaceva” il loro argomento; ho persino scritto uno script per farlo per tutti loro, generare un file CSV e caricarlo sul LMS universitario che non volevo utilizzare).
