Va bene. È un po’ un peccato dato che ho appena imposto i thread nei canali di supporto del nostro Discord per avere una migliore visione dei casi di supporto. E non sono sicuro che lo fornisca effettivamente, ma per fortuna ci sono altri vantaggi.
Hai una ETA per l’API e un’idea di quanto costerebbe supportare la funzionalità?
Ho sollecitato di recente e il lavoro è in fase di sviluppo da tempo. Solleciterò di nuovo e ti farò sapere, ma attenzione, l’ultima volta mi hanno detto “sarà fatto quando sarà fatto”… il problema con l’open source è spesso la mancanza di un buon modo per indirizzare livelli appropriati di finanziamento della community (o la loro assenza) per assistere con focus e prioritizzazione… vedremo…
Dal mio punto di vista, dovrei vedere l’implementazione finale per stimare lo sforzo.
La sfida potrebbe essere che, sebbene sia semplice copiare i messaggi, mantenere i Thread sincronizzati con gli Argomenti potrebbe richiedere una sorta di mappatura mantenuta in Discourse, ad esempio un campo personalizzato o una tabella che mappa i Thread di Discord agli Argomenti di Discourse, in modo che quando un nuovo messaggio viene aggiunto a un Thread, si sappia dove inserirlo in Discourse.
Puoi elaborare esattamente sulla funzionalità/comportamento che stai cercando?
Sì, è brutto dipendere da qualcosa che non puoi influenzare.
La mia idea è molto ispirata all’articolo e alla discussione sul blog di Discourse su quanto bene Discord e Discourse si completino a vicenda. Quando abbiamo avviato il nostro server Discord quasi due mesi fa, non sapevamo davvero come si sarebbe evoluto e come avrebbe influenzato il nostro forum Discourse esistente (ma a malapena configurato), ma sembra che le persone lo utilizzino ancora, così come il nostro Discord, per porre domande di supporto tecnico (lavoro con il progetto FOSS CrowdSec). Quindi, fondamentalmente, sono completamente d’accordo con l’idea di utilizzare Discourse come memoria a lungo termine e sincronizzare i thread di Discord con Discourse sotto argomenti che corrispondono ai canali Discord (e viceversa). Il modo in cui la vedo io, può essere fatto in modo molto più efficace (ad esempio, automatizzato) utilizzando i thread.
Come ho detto, ho recentemente imposto i thread su Discord, il che significa che non è sempre molto facile avere una panoramica dei thread per i nostri sviluppatori che sono assegnati al supporto utenti. Quindi voglio usare la sincronizzazione con Discourse anche come un buon modo per tenerli aggiornati sulle domande a cui rispondere, senza essere troppo risucchiati dal chiacchiericcio di Discord.
Ha senso? E c’è qualche altro modo per raggiungere questo obiettivo in tempi più brevi, magari?
Ti scrivo qui perché non credo che il mio problema su GitHub sia stato visto e penso che questo sia il posto migliore.
Abbiamo riscontrato un errore che abbiamo ricondotto al plugin del bot Discord. L’immagine sopra mostra l’errore dell’elemento di ispezione, ma qualsiasi utente che invia un PM riceve anche un errore visivo “500 Error” quando il suo PM viene inviato. Il PM viene comunque inviato con successo, ma questo errore fa sembrare il contrario. Dopo aver disabilitato il plugin, il problema non esiste più.
Sono abbastanza sicuro che il problema provenga da /lib/discourse_event_handlers.rb. Presumo che un PM stia attivando l’evento Discourse post_created, che lo fa tentare di accedere alla categoria del post tramite posted_category = post.topic.category.id, causando l’errore.
Spero che questo aiuti e che possa essere risolto presto. Grazie.
Ciao, non so se è già stato chiesto, ma le credenziali OAuth devono essere le stesse dell’app? Perché al momento stiamo utilizzando un’altra integrazione di sincronizzazione Discord e i campi OAuth sono già compilati. Grazie.
Questo plugin è compatibile con la soluzione di accesso social ufficiale nel core. Il bot necessita di un token da un’app Discord autorizzata. L’accesso social consente al plugin di identificare lo stesso utente tra le due piattaforme.
Ciao!\nCercando nel forum un modo per dare agli utenti Discourse un livello di fiducia diverso in base a un account Discord mi ha portato qui.\n\nAbbiamo già una community piuttosto attiva su Discord e abbiamo introdotto Discourse di recente per discussioni più organizzate.\n\nSto cercando una soluzione che funzioni così. Un membro che accede con il proprio account Discord e ha un ruolo specifico su Discord riceve automaticamente un livello di fiducia 1 su Discourse.\n\nQuesto Bot Kit sarebbe il giusto punto di partenza per un’implementazione del genere?\n\nGrazie
Questo bot, per quanto ne so, è “unidirezionale” da Discourse a Discord. Non ci sono funzioni opposte integrate.
Personalmente, penso che sarebbe più facile realizzare questo con codice esterno che monitora il webhook degli eventi utente della tua installazione di Discourse.
Evento webhook in uscita → Recupera l’ID utente di Discord dal database di Discourse (richiede l’autenticazione Discord) → Recupera i ruoli usando discord.js, .py, ecc. → Assegna il ruolo con una richiesta API di Discourse
Per ottenere l’ID Discord, devi usare il plugin Data Explorer e creare la seguente query:
-- [params]
-- string :user
SELECT u.username, u.id, a.user_id, a.provider_name, a.provider_uid
FROM users u
JOIN user_associated_accounts a on a.user_id = u.id
WHERE u.username = :user
Puoi quindi consultare la documentazione del plugin Data Explorer ed eseguire quella query con una richiesta API per ottenere l’ID.
Sebbene questo sia vero per la sincronizzazione dei ruoli, per il resto non è corretto.
Dall’OP:
Quindi, ci sono molti comportamenti da Discord a Discourse e ben lungi dall’essere solo un bot di “sincronizzazione dei ruoli”.
Come sempre, sono benvenuti i PR per qualsiasi funzionalità aggiuntiva generalmente utile. Sarebbe bello avere qualche aggiunta dalla community. :occhi:
Per mantenere la conoscenza aperta e indicizzata per tutti, è probabilmente meglio porre le domande qui. Discord è un buco nero per le informazioni. Le cose entrano e poi non vengono più ritrovate E altrimenti, abbiamo anche la chat qui su Discourse.
Ciao Kene, se non è di natura commerciale, ti saremmo grati se potessi fare qui le tue domande in modo che la community possa trarne beneficio (o anche rispondere).