Alles klar. Das ist ein bisschen Ă€rgerlich, da ich gerade Threads in den Support-KanĂ€len unseres Discords erzwungen habe, um einen besseren Ăberblick ĂŒber SupportfĂ€lle zu bekommen. Und ich bin mir nicht sicher, ob das tatsĂ€chlich so ist â aber zum GlĂŒck gibt es andere Vorteile.
Haben Sie eine ETA fĂŒr die API und eine Vorstellung davon, was es kosten wĂŒrde, das Feature zu unterstĂŒtzen?
Danke!
/k
Ich habe kĂŒrzlich nachgehakt und es ist schon seit einiger Zeit in der Entwicklung. Ich werde noch einmal nachhaken und mich melden, aber sei gewarnt, letztes Mal sagten sie mir: âEs wird fertig sein, wenn es fertig istâ ⊠Das Problem bei Open Source ist oft ein Mangel an einer guten Möglichkeit, angemessene Community-Finanzierung (oder deren Fehlen) zu lenken, um Fokus und Priorisierung zu unterstĂŒtzen ⊠wir werden sehen âŠ
Von meiner Seite aus mĂŒsste ich die endgĂŒltige Implementierung sehen, um den Aufwand abzuschĂ€tzen.
Die Herausforderung könnte darin bestehen, dass es zwar einfach ist, Nachrichten zu kopieren, aber die Synchronisierung von Threads mit Topics eine Art Mapping erfordert, das in Discourse gepflegt wird, z. B. ein benutzerdefiniertes Feld oder eine Tabelle, die Discord-Threads mit Discourse-Topics verknĂŒpft, sodass Sie beim HinzufĂŒgen einer neuen Nachricht zu einem Thread wissen, wo Sie sie in Discourse platzieren mĂŒssen.
Können Sie genau erlÀutern, welche FunktionalitÀt/welches Verhalten Sie suchen?
Das ist wirklich Àrgerlich, von etwas abhÀngig zu sein, das man nicht beeinflussen kann.
Meine Idee ist stark vom Artikel und der Diskussion im Discourse-Blog inspiriert, wie gut sich Discord und Discourse ergĂ€nzen. Als wir vor fast zwei Monaten unseren Discord-Server starteten, wussten wir nicht wirklich, wie er sich entwickeln und wie er unser bestehendes (aber kaum konfiguriertes) Discourse-Forum beeinflussen wĂŒrde, aber es scheint, dass die Leute ihn genauso gut nutzen wie unser Discord, um technische Supportfragen zu stellen (ich bin beim FOSS-Projekt CrowdSec). Im Grunde stimme ich der Idee voll und ganz zu, Discourse als langfristiges GedĂ€chtnis zu nutzen und Discord-Threads mit Discourse-Themen abzugleichen, die den Discord-KanĂ€len entsprechen (und umgekehrt). Ich sehe, dass dies durch die Verwendung von Threads viel effektiver (z. B. automatisiert) geschehen kann.
Wie gesagt, ich habe kĂŒrzlich Threads auf Discord erzwungen, was bedeutet, dass es fĂŒr unsere Entwickler, die dem Benutzersupport zugewiesen sind, nicht immer sehr einfach ist, einen Ăberblick ĂŒber die Threads zu bekommen. Daher möchte ich die Synchronisierung mit Discourse auch als gute Möglichkeit fĂŒr sie nutzen, um ĂŒber zu beantwortende Fragen auf dem Laufenden zu bleiben, ohne zu sehr in das Discord-Geplapper hineingezogen zu werden.
Macht das Sinn? Und gibt es vielleicht noch andere Möglichkeiten, dies in kĂŒrzerer Zeit zu erreichen?
Hallo @merefield!
Ich schreibe Ihnen hier, weil ich glaube, dass meine GitHub-Issue nicht gesehen wurde, und ich denke, dies ist der nÀchstbeste Ort.
Wir erhalten einen Fehler, den wir auf das Discord-Bot-Plugin zurĂŒckgefĂŒhrt haben. Das obige Bild zeigt den Fehler im Inspect-Element, aber jeder Benutzer, der eine PM sendet, erhĂ€lt auch eine visuelle â500-Fehlerâ-Meldung, wenn seine PM gesendet wird. Die PM wird trotzdem erfolgreich gesendet, aber dieser Fehler lĂ€sst es anders erscheinen. Nach dem Deaktivieren des Plugins besteht das Problem nicht mehr.
Ich bin ziemlich sicher, dass das Problem von /lib/discourse_event_handlers.rb stammt. Ich gehe davon aus, dass eine PM das DiscourseEvent post_created auslöst, was dazu fĂŒhrt, dass versucht wird, auf die Kategorie des Posts ĂŒber posted_category = post.topic.category.id zuzugreifen, was den Fehler verursacht.
Ich hoffe, das hilft und dass dies bald behoben werden kann. Danke.
Danke fĂŒr den Bericht. Klingt vernĂŒnftig. Vielleicht habe ich diese Woche die Gelegenheit, ihn mir anzusehen âŠ
Fantastisch, danke! Wir werden die Aktualisierung im Auge behalten. 
Ich weise darauf hin, dass ich im Moment mit Kundenarbeit ĂŒberhĂ€uft bin, daher wird dies möglicherweise eine Weile nicht bearbeitet.
In der Zwischenzeit wurde der PR akzeptiert.
Generell wĂŒrde ich mehr Community-BeitrĂ€ge zu den kostenlosen Plugins begrĂŒĂen.
Bei mir ist es gerade ziemlich voll, aber ich habe das eingereicht, was ich fĂŒr eine Korrektur halte:
Scheint jetzt zu funktionieren und die gefĂŒrchtete 500 bei PMs ist weg âŠ
Oh, das ist wunderbar und ersetzt Discord Chat!
Soll es die Slug-Namen auf Discourse lesen oder nur die Titel?
Discord wird nicht auf die gleiche Weise ĂŒber Slugs verwaltet, daher sind es, wenn ich mich recht erinnere, Titel.
Hallo, ich weiĂ nicht, ob das schon einmal gefragt wurde, aber mĂŒssen die OAuth-Anmeldeinformationen mit denen der App ĂŒbereinstimmen? Denn im Moment verwenden wir eine andere Discord-Sync-Integration und die OAuth-Felder sind bereits ausgefĂŒllt. Danke.
Dieses Plugin ist mit der offiziellen Social-Login-Lösung im Kern kompatibel. Der Bot benötigt ein Token von einer autorisierten Discord-App. Das Social Login ermöglicht es dem Plugin, denselben Benutzer auf beiden Plattformen zu identifizieren.
Danke fĂŒr die Antwort! Ich werde noch ein wenig mehr debuggen, um zu sehen, was mir bei der Einrichtung fehlt.
Ich glaube nicht, dass es dieselbe Discord-App sein muss, aber probier es aus!
Hallo hier!
Bei der Suche im Forum nach einer Möglichkeit, den Discourse-Benutzern basierend auf einem Discord-Konto ein anderes Vertrauensniveau zu geben, bin ich hier gelandet.
Wir haben bereits eine ziemlich aktive Community auf Discord und haben kĂŒrzlich Discourse fĂŒr besser organisierte Diskussionen eingefĂŒhrt.
Ich suche nach einer Lösung, die wie folgt funktioniert: Ein Mitglied, das sich mit seinem Discord-Konto anmeldet und eine bestimmte Rolle auf Discord hat, erhÀlt automatisch ein Vertrauensniveau 1 auf Discourse.
WĂ€re dieses Bot Kit der richtige Ausgangspunkt fĂŒr eine solche Implementierung?
Danke
Soweit ich weiĂ, ist dieser Bot âeinseitigâ von Discourse zu Discord. Es gibt keine Funktionen, die umgekehrt eingebaut sind.
Ich persönlich denke, es wĂ€re einfacher, dies mit externem Code zu erreichen, der den Webhook der Benutzerereignisse Ihrer Discourse-Installation ĂŒberwacht.
Webhook-Ereignis raus â Discord-Benutzer-ID aus der Discourse-Datenbank abrufen (erfordert Discord-Authentifizierung) â Rollen mit discord.js, .py usw. abrufen â Rolle mit Discourse-API-Anfrage zuweisen
Um die Discord-ID zu erhalten, mĂŒssen Sie das Data Explorer-Plugin verwenden und die folgende Abfrage erstellen:
-- [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
Sie können dann die Dokumentation des Data Explorer-Plugins einsehen und diese Abfrage mit einer API-Anfrage abrufen, um die ID zu erhalten.
Ich hoffe, das hilft ein wenig.
WĂ€hrend dies fĂŒr die Rollensynchronisierung gilt, ist dies ansonsten nicht korrekt.
Aus der OP:
Also viel Discord â Discourse-Verhalten und weit davon entfernt, nur ein âRollensynchronisierungsâ-Bot zu sein.
Wie immer sind PRs fĂŒr jede allgemein nĂŒtzliche zusĂ€tzliche FunktionalitĂ€t willkommen. Es wĂ€re gut, einige ErgĂ€nzungen aus der Community zu haben. 
Vielen Dank fĂŒr diesen Beitrag @merefield
Könnte ich deine Discord-ID bekommen? Ich wĂŒrde dir gerne ein paar Fragen stellen, wenn das in Ordnung ist.
Um Wissen fĂŒr alle offen und indizierbar zu halten, ist es wahrscheinlich am besten, die Fragen hier zu stellen. Discord ist ein schwarzes Loch fĂŒr Informationen. Zeug geht rein und wird dann nie wieder gefunden 
Und ansonsten haben wir hier auch Chat auf Discourse.
Hallo Kene, wenn es nicht kommerzieller Natur ist, wĂŒrde ich es zu schĂ€tzen wissen, wenn Sie Ihre Fragen hier stellen könnten, damit die Community davon profitieren (oder sie sogar beantworten) könnte.