Вы имеете в виду, что ранее у вас были правила, которые обеспечивали ветвление, но после последнего обновления оно перестало работать? Или же вы ожидали, что с обновлением ветвление начнёт работать, но этого не происходит?
Я использую версию Discourse 093ee1d80c и discourse-chat-integration da91061 (актуальная версия). У меня каналы с правилами thread корректно ветвят ответы, но только для каналов, настроенных с использованием правил thread.
Можете ли вы показать конфигурацию правила для ветвления? В разделе Администрирование → Плагины → Интеграции чата вы должны увидеть правила, в которых указано:
Выше уже объяснялось, что это настройка на уровне правила, а не на уровне всего сайта.
При создании правила через команду /discourse в Slack (или через другую команду, выбранную вами при настройке интеграции), используйте thread вместо watch или follow, как описано в Discourse Chat Integrations
Хорошо, мне нужно пройтись по интеграциям Slack и заменить каждое вхождение: Все посты и ответы < Все посты с ответами в ветках.
На данный момент в большинстве интеграций каналов отображаются все посты и ответы. Не приведёт ли к проблемам переход на отображение только всех постов с ответами в ветках? Спрашиваю, потому что у меня много каналов, которые нужно перенастроить, поэтому лучше сразу правильно их переназначить.
Если я правильно понял ваш вопрос: нет, это ничего не «сломает» — функция задумана как безопасная, так как она никогда не помешает отправке нового уведомления в Slack. Просто если интеграция знает о существовании потока (thread), она отправит сообщение в этот поток вместо канала. Если по какой-то причине контекст потока неизвестен, сообщение будет отправлено в канал, как указано в правиле.
«Все сообщения с ответами в потоке» означает следующее:
Когда новое сообщение добавляется в существующую тему:
Если для темы сохранен ID потока, используйте его для отправки сообщения в поток.
Если для темы ID потока не сохранен, после отправки уведомления в Slack используйте ID потока нового сообщения в Slack для последующих сообщений по этой теме. С этого момента начнется использование потоков.
Когда новая тема публикуется в Slack, сохраните полученный ID потока, чтобы дополнительные сообщения по этой теме отправлялись в Slack как ответы в потоке.
Я бы сформулировал это так: «работай точно так же, как режим «watch», но если известен поток для отправки, используй его».
Кроме того, при использовании функции «транскрипт» для публикации содержимого Slack в виде новой темы в Discourse, независимо от любых настроек правил, система всегда пытается сохранить ID потока. Это делается для того, чтобы, если правило threadлибо уже существует, либо будет добавлено в будущем, ответы на новую тему в Discourse анонсировались в соответствующем потоке Slack.
Я уверен, что ваши существующие правила можно изменить, выполнив некоторые команды через bin/rails c, но я не хочу вмешиваться в работу моего действующего сайта, где я намеренно выбрал, какие каналы использовать для потоков, а какие нет. К тому же я слишком новичок в Ruby, чтобы давать советы по вводу случайного кода на форуме и надеяться, что это не приведет к проблемам. Кроме того, что это, вероятно, начинается с DiscourseChat::Rule.where(, я не смогу вам сильно помочь. Извините!
@sunjam, кстати, я ценю ваше подтверждение того, что эта функция полезна и востребована! (Особенно учитывая иронию: мне самим не очень нравятся треды в Slack, но я сделал эту работу для тех, кто находит их более ценными, чем я!)
Представляю, что логично добавить в интерфейс кнопку для преобразования всех правил watch в правила thread. Однако я не обладаю достаточными знаниями, чтобы реализовать это, и сам бы ею не воспользовался. Я по сути бэкенд-разработчик, который немного экспериментирует с Discourse, поэтому даже не смогу стать полезным ревьюером для PR с такой кнопкой. Всё, что я могу, — это быть бесполезным болельщиком, если кто-то другой захочет реализовать подобную функциональность.
Я обнаружил проблему @mcdanlj. При создании новой интеграции канала: в тестовых сценариях 2.6 beta1 с фильтрами потоковые ответы не отображаются. После создания интеграции эта опция становится доступной при её редактировании.
Но я на самом деле бэкенд-разработчик и не знаю, как это исправить. Не понимаю, почему channel.provider равен slack только при редактировании существующего правила, а не при создании нового.
@sunjam Кстати, после того как я решил перенести большинство, но не все, свои правила интеграции с Slack из watch в thread, я испытал твою боль. Мои глаза, конечно, потускнели, и я был рад, когда всё закончилось. Так что не уверен, что стал бы что-то делать иначе в своей работе, но я не преуменьшаю объём работы, необходимый для конвертации. По крайней мере, это разовые затраты.
Если бы существовала команда в одну строку, которую можно было бы выполнить в консоли Rails для конвертации всех обычных правил watch в правила thread, я бы её уже нашёл — или воспользовался бы ей, а затем обратно конвертировал бы несколько правил, которые хотел оставить как watch.
Появляются ли ответы в потоках в разделах Все непрочитанные и Потоки на вашей стороне Slack? Я видел, что появляются новые сообщения, но ответы в потоках, похоже, не вызывают эти уведомления.
Сообщения, публикуемые в Discourse, не уведомляют иначе, чем любые другие потоки в Slack, но это уже выходит за рамки Discourse и касается того, как работают уведомления о потоках в Slack. Мне кажется, что правила уведомлений о потоках в Slack не идеальны, но Slack — это не проект с открытым исходным кодом, в который случайные люди могут вносить улучшения. Чтобы получать уведомления о новых сообщениях в потоке, нужно либо участвовать в этом потоке, либо подписаться на него. По крайней мере, таковы правила на этой неделе. Когда потоки только появились в Slack, они, кажется, следовали правилам уведомлений канала. Я не могу найти в Slack настройки, позволяющие потокам наследовать правила уведомлений канала, и это сводит меня с ума, потому что из-за этого я пропускаю важную информацию на работе.
Мне настолько не нравится реализация потоков в Slack, что это действительно иронично, учитывая, что именно я реализовывал эту функцию. Но я также думаю, что я в меньшинстве: я внедрил её, чтобы сделать Discourse более привлекательным для большинства, которые действительно ценят потоки в Slack.
Спасибо за уточнение. Похоже, что участники ThreadExample увидят ответы в виде веток, что вполне подходит. В любом случае, это очень полезная опция для уменьшения загромождения в Slack, и я надеюсь, что она вдохновит другие интеграции чатов внедрить подобные вариации этой концепции!
Это правда, под «участниками» подразумеваются те, кто нажимает на меню из трёх вертикальных точек в теме и выбирает «Подписаться на тему» (первый вариант).
Я только что заметил, что в теме ранее были макеты, но я никогда не приводил пример работы этой функции. Поэтому с сегодняшнего дня в канале Slack для https://forum.makerforums.info/c/k40 у нас есть следующее:
Большое спасибо за настройку синхронизации тем Discourse в Slack. Я заметил одну проблему: если я публикую ссылку с onebox, вставляя её на отдельной строке, она полностью исчезает в сообщении, отправленном в поток Slack, и я вижу только пустую строку. В моём случае ссылка была помещена между двумя строками текста, и они были опубликованы без проблем.
Ничто из того, что я сделал, не изменило содержимое опубликованного сообщения; это лишь иногда устанавливает целевую ветку.
Я предлагаю создать отдельный отчёт об ошибке в отдельной ветке для проблем с форматированием сообщений, публикуемых в Slack. Я не рассматривал и не затрагивал это.
кратко: перемещение тем — плохая идея при потоковой отправке ответов в Slack.
Я заметил, что перемещение темы между категориями в Discourse, похоже, нарушает потоковую отправку ответов в каналах Slack. Речь идёт о ситуации, когда пользователь создаёт тему в одной категории, а затем перемещает её в другую категорию, связанную с другим каналом Slack.
Поскольку Пост А был перемещён, он больше не отправляет потоковые ответы в то же место в Slack. Это означает, что ответы вообще не видны в Slack. Если вы будете сохранять ответы отдельными сообщениями (не в потоке), вы избежите этой потенциальной проблемы.
Не уверен, но, думаю, стоит отметить. Один из обходных путей — сделать интеграцию доступной в конкретном дополнительном канале Slack без ветвления, просто чтобы она отображалась хотя бы в одном канале.
Кроме того, что это, вероятно, начинается с 
