Ладно. Немного обидно, ведь я только что включил потоки в каналах поддержки нашего Discord, чтобы лучше отслеживать обращения в поддержку. И я не уверен, что это действительно поможет, но, к счастью, есть и другие преимущества.
У вас есть примерные сроки выхода API и представление о том, сколько будет стоить поддержка этой функции?
Спасибо!
/k
Я недавно связывался с ними, и разработка идёт уже какое-то время. Я ещё раз свяжусь и отчитаюсь, но предупреждаю: в прошлый раз мне сказали «сделаем, когда будет готово»… Проблема с открытым исходным кодом часто заключается в отсутствии хорошего способа направлять соответствующий уровень финансирования сообщества (или его отсутствие) для помощи в фокусировке и приоритизации… посмотрим…
Со своей стороны, я мог бы оценить объём работ только после ознакомления с окончательной реализацией.
Сложность может заключаться в том, что, хотя копирование сообщений — дело простое, синхронизация потоков с темами может потребовать какого-то механизма сопоставления, поддерживаемого в Discourse, например, пользовательского поля или таблицы, которая сопоставляет потоки Discord с темами Discourse, чтобы при добавлении нового сообщения в поток вы знали, куда его разместить в Discourse.
Можете ли вы подробнее описать именно ту функциональность и поведение, которые вы ищете?
Да, это неприятно, когда приходится зависеть от чего-то, на что ты не можешь повлиять.
Моя идея сильно вдохновлена статьёй и обсуждением в блоге Discourse о том, как хорошо Discord и Discourse дополняют друг друга. Когда мы почти два месяца назад запустили наш сервер Discord, мы не совсем понимали, как он будет развиваться и как повлияет на наш существующий (но едва настроенный) форум Discourse. Однако оказалось, что люди по-прежнему используют его наравне с Discord для запросов технической поддержки (я работаю над FOSS-проектом CrowdSec). В целом, я полностью поддерживаю идею использовать Discourse как долгосрочное хранилище знаний и синхронизировать потоки Discord с темами Discourse, соответствующими каналам Discord (и наоборот). На мой взгляд, с использованием потоков это можно сделать гораздо эффективнее (например, автоматически).
Как я уже говорил, я недавно включил потоки на Discord, из-за чего не всегда легко получить обзор потоков для наших разработчиков, назначенных на поддержку пользователей. Поэтому я хочу использовать синхронизацию с Discourse также как удобный способ держать их в курсе вопросов, на которые нужно ответить, не погружаясь слишком сильно в болтовню Discord.
Имеет ли это смысл? И есть ли другой способ достичь этого в более короткие сроки?
Привет, @merefield!
Я пишу вам сюда, потому что думаю, что мой запрос в GitHub остался без внимания, и это следующее лучшее место для обращения.
Мы столкнулись с ошибкой, которую удалось связать с плагином Discord-бота. На изображении выше показана ошибка из инструментов разработчика, но любой пользователь, отправляющий личное сообщение (PM), также видит визуальное сообщение об ошибке «500» после отправки PM. Само сообщение отправляется успешно, но эта ошибка создаёт впечатление обратного. После отключения плагина проблема исчезает.
Я почти уверен, что проблема исходит из файла /lib/discourse_event_handlers.rb. Предполагаю, что при отправке PM срабатывает событие DiscourseEvent post_created, из-за чего система пытается получить категорию сообщения через posted_category = post.topic.category.id, что и вызывает ошибку.
Надеюсь, это поможет, и что проблема будет решена как можно скорее. Спасибо.
Спасибо за отчет. Звучит вполне логично. Возможно, на этой неделе у меня будет возможность это посмотреть…
Отлично, спасибо! Мы будем следить за обновлением. 
Предупреждаю, что сейчас я тонну в работе с клиентами, так что это может быть рассмотрено не скоро.
Тем временем PR принят.
В целом я приветствую больше вкладов от сообщества в бесплатные плагины.
Сейчас у меня довольно много дел, но я выкатил то, что считаю исправлением:
Кажется, теперь всё работает, и проклятая ошибка 500 на личных сообщениях исчезла…
О, это замечательно и заменяет Discord Chat!
Должно ли оно считывать слайги (slug) на Discourse или только заголовки?
Discord не управляет с помощью слаг-ов так же, поэтому, насколько я помню, используются заголовки.
Привет! Не уверен, задавали ли этот вопрос раньше, но должны ли OAuth-учетные данные совпадать с данными приложения? Дело в том, что мы сейчас используем другую интеграцию для синхронизации с Discord, и поля OAuth уже заполнены. Спасибо.
Этот плагин совместим с официальным решением для входа через социальные сети, встроенным в ядро. Боту требуется токен от авторизованного приложения Discord. Функция входа через социальные сети позволяет плагину идентифицировать одного и того же пользователя на обеих платформах.
Спасибо за ответ! Я немного поотлажу, чтобы понять, чего мне не хватает в настройке.
Я не думаю, что это должно быть то же самое приложение Discord, но попробуй!
Привет!
Поиск в форуме способа присвоения пользователям Discourse разного уровня доверия на основе учётной записи Discord привёл меня сюда.
У нас уже есть довольно активное сообщество в Discord, и недавно мы добавили Discourse для более структурированных обсуждений.
Меня интересует решение следующего типа: участник, который входит в систему через учётную запись Discord и имеет определённую роль в Discord, автоматически получает уровень доверия 1 в Discourse.
Является ли этот Bot Kit подходящей отправной точкой для такой реализации?
Спасибо.
Насколько мне известно, этот бот работает только в одном направлении — из Discourse в Discord. Функций, работающих в обратном направлении, в нём не предусмотрено.
Лично я думаю, что вам будет проще реализовать это с помощью внешнего кода, который будет отслеживать вебхук событий пользователей вашего установочного экземпляра Discourse.
Исходящее событие вебхука → Получение ID пользователя Discord из базы данных Discourse (требуется использование аутентификации через Discord) → Получение ролей с помощью discord.js, .py и т. д. → Назначение роли через запрос к API Discourse
Чтобы получить ID пользователя Discord, вам нужно использовать плагин Data Explorer и создать следующий запрос:
-- [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
Затем вы можете обратиться к документации плагина Data Explorer и выполнить этот запрос через API, чтобы получить ID.
Надеюсь, это хоть немного поможет.
Хотя это верно для синхронизации ролей, в остальном это не так.
Из первого сообщения темы:
Таким образом, бот поддерживает множество сценариев работы от Discord к Discourse и далеко не ограничивается лишь «синхронизацией ролей».
Как всегда, приветствуются pull-реквесты с добавлением полезного функционала. Было бы здорово получить предложения от сообщества. 
Спасибо за этот пост, @merefield!
Можно узнать ваш Discord? Я бы хотел задать вам несколько вопросов, если это не проблема.
Чтобы знания оставались открытыми и доступными для поиска всем, лучше задавать вопросы здесь. Discord — это чёрная дыра для информации: информация туда попадает, но потом её уже никогда не найти 
. Кроме того, у нас здесь, на Discourse, тоже есть чат.
Привет, Кене, если это не носит коммерческого характера, буду признателен, если вы зададите свои вопросы здесь, чтобы сообщество могло извлечь из них пользу (или даже ответить на них).