È questo un caso d'uso per i campi personalizzati utente?

Sto cercando di capire come permettere agli utenti di creare sottopubblici che funzionino come canali Slack.

Uno dei suggerimenti era di utilizzare i tag. Quindi un utente creerebbe un tag (o un’app che ho sviluppato lo farebbe tramite l’API), e la pagina del tag funzionerebbe come la pagina del sottopubblico.

La domanda è allora: come fare in modo che solo i membri del sottopubblico possano pubblicare in quel sottopubblico? In altre parole, solo i membri di quel sottopubblico potrebbero avere il tag del sottopubblico collegato ai loro post.

Esiste un modo per utilizzare i “campi personalizzati utente” per ottenere questo risultato? In qualche modo per contrassegnare un utente come autorizzato a pubblicare con un determinato tag?

Non ho ben chiaro a cosa servano i campi personalizzati utente, quindi spero di capirne di più.

Credo che i tag non includano permessi a livello utente. Potresti voler controllare invece le categorie.

Discourse utilizza gruppi e categorie per controllare l’accesso ai contenuti. Dai un’occhiata al video in questo argomento per i dettagli: Come utilizzare le impostazioni di sicurezza delle categorie per creare categorie private

Grazie per le risposte, ragazzi. Concordo sul fatto che le categorie sembrino la via più semplice per farlo. Tuttavia, si tratterebbe di sottopost in cui gli utenti potrebbero crearne molti. Potrebbero essercene centinaia o più (i sottopost sono un elemento chiave dell’app, quindi cresceranno man mano che aumenta la base utenti).

Mi è stato detto che creare centinaia/migliaia di categorie sarà un grosso problema, quindi dovrei cercare altre soluzioni. Avete altri suggerimenti? Sono disposto a costruire un’app separata che interagisca con l’API. La cosa fondamentale che voglio da Discourse è la straordinaria funzionalità di post/risposta/tag.

Quello che vuoi creare non è l’obiettivo di Discourse.

Tu desideri una piattaforma simile a Reddit o Discord, dove le persone possano entrare e creare subreddit/server di cui si “sentono proprietari”, mentre tu mantieni il controllo totale e la monetizzazione della piattaforma.

Discourse mira esattamente all’opposto, permettendo a ogni subreddit/server/gilda di essere un sito a sé stante, di possedere i propri dati e di operare nel proprio URL.

Anche se è possibile modificare notevolmente un progetto open source, ti consiglio di utilizzare un’alternativa più vicina alle tue esigenze.

Apprezzo che questo non sia il caso d’uso normale, ma vorrei assolutamente trovare un modo per farlo con Discourse, dato quanto è fantastico. E posso arrivare abbastanza vicino: creo un tag tramite l’API e invio gli utenti alla pagina del tag, che funziona come una pagina di sottosezione. La parte fondamentale che mi manca è la possibilità di limitare gli utenti che possono pubblicare con quel tag.

Discord non funzionerebbe per questi scopi a causa delle limitazioni che ha nell’integrazione con le app. Non conosco bene come si potrebbe integrare Reddit con un’app.

Stai suggerendo che potrei effettivamente far funzionare questa soluzione con Reddit, o intendevi solo che è il “tipo” di funzionalità che ho in mente?

In ogni caso, il vantaggio principale di Discourse, dal mio punto di vista, è che è un forum, non una chat. E la funzionalità simile a un forum è proprio ciò che desidero qui. Non ho visto alternative a Discourse che possano funzionare in questo senso, ma sono assolutamente aperto a suggerimenti.

Quella parte fondamentale non è prevista nella roadmap e non abbiamo intenzione di aggiungerla.

Negli anni sono stati creati molti argomenti a riguardo:

Ho visto quelle discussioni. Una differenza qui è che sono disposto a sviluppare un’app completamente separata che interagisce con l’API di Discourse per offrire all’utente l’esperienza di creazione di un sottogruppo. In questo modo, posso creare il sottogruppo direttamente nella mia app separata, associare i membri ad esso, ecc.

Tuttavia, vorrei comunque poter utilizzare le funzionalità di pubblicazione dell’interfaccia front-end di Discourse (creazione di argomenti, risposte, collegamenti alle categorie e aggiunta di tag, principalmente) sulla pagina del sottoforum creata dalla mia app.

Mi è stato detto che esiste un modo per collegare i campi personalizzati degli utenti ai tag, o qualcosa di simile, per limitare i tag a cui un utente può pubblicare.

Ma la speranza di fondo è quella che ho già menzionato: posso occuparmi di gran parte della configurazione del sottoforum dal lato della mia app, ma sarebbe un enorme risparmio di tempo poter comunque utilizzare le funzionalità di pubblicazione di Discourse.

Apprezzo tutte le risposte. Qualcuno potrebbe fornire alcuni esempi di come vengono solitamente utilizzati i campi personalizzati degli utenti?

Sembra che potrei semplicemente aggiungere un campo personalizzato relativo al sottoforum specifico (ad esempio, ‘subforum123’) a ogni utente autorizzato, e poi, quando un utente visita la pagina di un sottoforum, chiamare l’API per verificare se l’utente possiede il campo personalizzato richiesto. Se sì, allora può pubblicare lì. Se no, non può, e forse potrei semplicemente nascondere i pulsanti “nuovo argomento” e “rispondi”.

Vengono generalmente utilizzati per raccogliere informazioni (luogo, titolo professionale, ecc.) al momento della registrazione, che vengono visualizzate sulla scheda del profilo.

Forse quello che vuoi fare è permettere alle persone di creare il proprio Discourse (ad esempio username.tuosito.com) che giri su un’installazione multisito, con il tuo Discourse “principale” come server SSO per il sottosito dell’utente. Potresti teoricamente creare un plugin che generi un nuovo sito Discourse username.tuosito.com ogni volta che viene creato un nuovo utente. Ma forse non tutti gli utenti desiderano avere il proprio sottoforum e invece potresti avere . . . qualcosa . . . che permetta loro di creare il proprio sottosito.

Penso che questo si stia avvicinando a quello che stai cercando di fare.

Questo si avvicina davvero a ciò che ho in mente (gli “sotto-forum” sono l’obiettivo). Grazie. Darò un’occhiata più da vicino al multisito.

Avrei pensato che permettere agli utenti di creare il proprio sotto-sito in una struttura multisito fosse molto più dispendioso in termini di risorse rispetto, ad esempio, a permettere loro di creare le proprie categorie. Il multisito potrebbe funzionare con centinaia o più sotto-siti? Mi chiedo quanto carico questo possa mettere sul server, o forse non è molto più gravoso di un singolo sito molto attivo?

Lo è, ma ha il vantaggio di essere possibile.

Sì, sono a conoscenza di almeno un’azienda che gestisce centinaia o più sottositi con almeno due diversi set di plugin, a un costo di 100-300 dollari al mese. Altri applicano una tariffa di 20 dollari al mese per sito.

Nel caso non fosse chiaro, stai essenzialmente costruendo un’azienda di hosting per Discourse.

Per iniziare, ad esempio per alcune decine di siti, ti serviranno tra 4 e 16 GB di RAM.

Per confermare, intendi dire che quell’azienda paga 100-300 dollari al mese per mantenere centinaia di siti secondari? (sembra sia questo il senso della tua affermazione: una cifra piuttosto bassa per centinaia di siti secondari)

Intendo dire che una certa azienda (quella che sviluppa Discourse) addebita 100-300 dollari a sito che intendi creare. Altre aziende applicano tariffe nell’ordine dei 20 dollari al mese; presumibilmente stanno guadagnando bene.

Probabilmente servono almeno cento ore per risolvere il problema che ho proposto. Ma probabilmente di più.

EDIT: Ma forse, se ti serve semplicemente un singolo sito multisito, potresti avviarlo in meno tempo di così.

Ok. Ho capito. Grazie per le informazioni.