In sostanza, speriamo di creare gruppi per gestire i permessi di pubblicazione all’interno di un argomento, ma vogliamo comunque che ogni utente e gli ospiti non registrati possano leggere ciò che viene pubblicato.
Capisco che tu possa farlo per una categoria, ma speriamo di non dover creare un’intera nuova categoria dato che tutti questi argomenti sono già ordinatamente suddivisi in categorie e sottocategorie.
Speriamo davvero nella possibilità di limitare le risposte (e anche i like) su base per-argomento.
Ah, mi dispiace @orangeandblack5, non stavo considerando la tua domanda originale, stavo solo rispondendo a questa parte:
Ricominciamo…
In Discourse impostiamo i permessi dei gruppi a livello di categoria, non a livello di post, quindi non credo ci sia un modo per fare ciò che chiedi.
Sono curioso: perché non vuoi che chiunque possa leggere gli argomenti possa anche mettere like? Ho pensato all’archiviazione perché forse volevi “congelarli”, ma sembra che tu voglia che alcune persone abbiano la possibilità di mettere like e altre no. Adoro sentire come le persone usano Discourse nelle loro comunità!
Per noi, la parte di pubblicazione è molto più importante della parte di apprezzamento, ma in generale usiamo Discourse per gestire vari tipi di giochi e discussioni online a cui le persone devono iscriversi per partecipare, ed è contro le regole pubblicare in un gioco a cui non si sta effettivamente giocando, ma non abbiamo alcun controllo software su questo e quindi a volte i nuovi utenti si confondono e finiscono per interrompere le cose per errore quando invece dovrebbero iscriversi a un argomento imminente.
Un modo per consentire a tutti di leggere tutti gli argomenti, ma impedire a persone non iscritte a un particolare argomento di pubblicare in esso sarebbe fantastico!
Penso anche che l’unico modo per raggiungere questo obiettivo senza codice personalizzato sia aggiungere una sottocategoria dedicata per ogni gioco o discussione che si desidera limitare. Sembra macchinoso, ma dato che è già necessario impostare un gruppo dedicato ogni volta, in realtà non è uno sforzo manuale molto maggiore. In ogni caso, l’esperienza utente sarà pulita con una configurazione del genere:
categoria: giochi
permesso: tutti leggono
sottocategoria: gioco-A
permesso: solo il gruppo gioco-A risponde
Quindi gli argomenti del gioco-A saranno visibili a tutti, ma chiunque non sia membro del gruppo gioco-A e apra l’argomento non sarà in grado di rispondere.
Se desideri un’interfaccia molto pulita e si allinea con la tua architettura, potresti persino nascondere i badge delle sottocategorie pertinenti dall’interfaccia con css. Quindi le sottocategorie riguarderanno puramente i diritti di accesso e non la navigazione.
Il problema è che utilizziamo già delle sottocategorie per ordinare le cose.
Lo prenderemo almeno in considerazione, ma non è proprio l’ideale perché dovremmo eliminare un intero livello di ordinamento/organizzazione e ciò potrebbe rendere il sito molto più difficile da navigare, specialmente per i nuovi utenti.
Questo è separato dal caso d’uso dell’OP, ma gestisco un forum con una categoria solo anonima in cui gli utenti possono pubblicare su questioni professionali senza esporre i propri nomi utente a tutti gli altri (anche se sanno che gli amministratori possono scoprire chi ha pubblicato cosa se qualcuno si comporta male). Sarebbe fantastico poter limitare i “mi piace” solo agli utenti anonimi.
Ho la stessa situazione: utilizziamo Discourse come parte del nostro LMS personalizzato e a volte volevamo limitare l’accesso a un argomento in un corso a determinate coorti del corso.
Quindi l’unico modo per farlo (come spiegato sopra) è creare una categoria per il corso e poi una sottocategoria per ogni coorte che necessita di limitare l’accesso… quindi copiare ogni argomento in ogni sottocategoria, il che è un po’ una seccatura, inclusa la necessità di avere modelli dalla nostra parte che riflettano questa configurazione e codice per mantenere le cose sincronizzate.
Sarebbe molto più fantastico se potessimo limitare i post in ogni argomento ai gruppi.
\n\nOgni persona deve raggiungere le risposte di tutte le altre coorti?\n\nSe dovessi configurarlo, metterei i materiali in una categoria che non consente risposte, solo come materiale di riferimento.\n\nPoi, invierei un PM di gruppo collegando al materiale e tenendo lì la discussione.\n\nIn questo modo organizzi semplicemente le coorti in gruppi e puoi riutilizzare facilmente i materiali. ^_^\n\n[quote="Daniel McQuillen, post:15, topic:231228, username:Daniel_McQuillen"]\nSarebbe moooolto più fantastico se potessimo limitare i post in ogni argomento ai gruppi.\n[/quote]\n\nÈ così che funzionano i PM! Ma non per gli argomenti pubblici.
@maiki Wooooah. Non lo sapevo. Grazie per aver condiviso!!!
Tuttavia, con la strategia attuale, è una specie di “imposta e dimentica”. Quando un corso viene creato, possiamo creare l’argomento e la sottocategoria per la coorte PREDEFINITA e quindi popolare gli argomenti che desideriamo. Se viene aggiunta una nuova coorte, creiamo un nuovo gruppo e una nuova sottocategoria e copiamo gli argomenti.
Quindi possiamo dimenticarcene e gestire solo gli avvisi di attività tramite il callback.
Con l’approccio che hai descritto, sarebbe più lavoro manuale? “Inviare un PM di gruppo” suona come un’attività che si svolge durante la vita di un corso. Se un nuovo studente si iscrive a un corso esistente e viene inserito in una certa coorte, possiamo aggiungerlo al gruppo corretto in Discourse e quindi avrà accesso alla sottocategoria esistente (per quella coorte) e alla sua copia di tutti gli argomenti. In questo caso, verrebbe automaticamente aggiunto a un “PM di gruppo” esistente, quindi nessuna differenza nel flusso di lavoro?
L’interfaccia utente apparirebbe la stessa? Attualmente abbiamo solo l’argomento e poi tutti i post (per una particolare coorte, se necessario) sotto di essi, secondo la “solita” interfaccia utente di Discourse.
Devo dire che odio dover fare le sottocategorie e le copie di tutti gli argomenti ogni volta che viene creata una nuova coorte da parte nostra, e dover gestire questo, quindi questo PM diretto sembra intrigante. Ma ho questa apprensione nell’usare un “messaggio privato” per fare tutto ciò che una categoria + argomenti possono fare, mi manca qualcosa.
Non riesco davvero a immaginare come appaia per gli utenti.
So solo che spesso linko ad argomenti o uso modelli per riutilizzare il contenuto nei PM quando lavoro con contenuti riutilizzabili.
Se vuoi approfondire un po’ quello che stai facendo, con un esempio di argomenti e risposte degli studenti, in modo da poter vedere qual è l’esperienza della coorte, sarò lieto di ideare come realizzarla utilizzando i PM.
Quello che ho fatto è stato creare una categoria di sola lettura con i compiti e ho fatto in modo che gli studenti rispondessero come “argomento collegato” quando “rispondevano” al compito postando nella categoria della classe. Non sono sicuro di quanto sia facile trovare “rispondi come argomento collegato” su un post di sola lettura al giorno d’oggi.
Grazie @pfaffman e @maiki per i vostri pensieri. Il modo in cui abbiamo integrato gli argomenti è utilizzare l’API per recuperare i post più recenti di un argomento e mostrarli direttamente nella pagina dell’unità didattica pertinente nel nostro LMS:
Quindi, quando fai clic su “Partecipa alla discussione”, vieni portato all’argomento nella categoria del corso e nella sottocategoria della tua coorte nel corso, limitandoti così ai commenti dei tuoi compagni di coorte:
Questo costringe lo studente a capire perché c’è una categoria di livello superiore e poi un livello di sottocategoria per i “Topics del corso” (quella per la sua coorte), e un’altra per “Discussione generale” (quella per tutte le coorti in un corso)… e se fa clic in giro potrebbe un po’ perdersi.
A volte le coorti sono più un meccanismo di raggruppamento amministrativo, non qualcosa a cui lo studente tiene, quindi questo sistema di categorie/sottocategorie può creare un po’ di confusione. “Perché non c’è solo una categoria per tutti gli argomenti del corso?”
Inoltre, come ho menzionato in precedenza, questa configurazione significa che dobbiamo duplicare tutti gli argomenti ogni volta che viene creata una coorte, eliminare tale sottoinsieme quando una coorte viene eliminata o aggiornare ogni sottocategoria quando un argomento viene creato/aggiornato/eliminato.