Спасибо, это помогло!
@gilles Я уже реализовал последующее действие, о котором упоминал выше:
Оно добавляет универсальную операцию Событие → Установить посещаемость, которая включает:
- участника
- состояние посещаемости: Иду / Интересует / Не иду / Удалить посещаемость
- ID темы
- необязательного актора
Таким образом, ваш исходный сценарий можно реализовать следующим образом:
Создание поста → Если это первый пост → Событие / Установить посещаемость
используя автора события в качестве участника и устанавливая ему статус Иду.
Я протестировал именно этот шаблон локально в интерфейсе Workflows, наложив его на #42932, и подтвердил, что пользователь автоматически регистрируется как «Иду» на событии.
PR пока находится в статусе черновика, так как зависит от #42932. Как только #42932 будет объединён, я пересоберу его на основе main, что оставит только изменения, связанные с посещаемостью.
@Ethsim2 Спасибо, ты просто супер!
![]()
Существует ли способ повторить выполнение рабочего процесса (с тем же событием), аналогично тому, как можно повторно отправить загрузку (payload) через вебхук?
Нет, извините, мы пока это не поддерживаем
Существует ли триггер или событие, которое срабатывает при создании НОВОЙ метки?
Когда пользователь создаёт новую метку, можно ли автоматически добавить её в определённую группу меток? Если нет, какой подход рекомендуется?
Нет, у нас ничего из этого нет. Не могли бы вы подробнее описать ваш сценарий использования?
Можно ли сделать так, чтобы:
- он рассматривал все новые темы;
- сверял тег с уже существующими;
- если тег новый —
<insert action>.
Существует событие «Изменение метки темы». Вы можете затем вызвать API Discourse и посмотреть, сколько раз используется данная метка. Если она встречается один раз / находится именно в этой теме, значит, метка новая.
Альтернативный, возможно, более простой вариант: настроить вебхук для события «метка создана» и указать его на триггер вебхука в workflow.
Сценарий: у меня есть группа тегов «artist» (исполнитель). Новые исполнители появляются постоянно, поэтому, когда пользователи создают новые теги, они автоматически появляются в системе. Я хочу, чтобы эти новые теги автоматически добавлялись в группу тегов «artist», а не добавлялись вручную. Есть ли хороший способ добиться этого с помощью Workflows?
Как вы можете быть уверены, что это тег исполнителя, а не какой-нибудь другой случайный тег?
Именно этим занимается этап с ИИ. Агент ИИ сначала определяет, относится ли новый тег к одной из заранее определённых групп (артист / участник / регион / тип события / тип релиза); если он не подходит ни к одной из них, тег пропускается и никогда не попадает в группу. Таким образом, случайные теги отфильтровываются, а только правильно классифицированные теги автоматически добавляются в группу тегов.
ок, добавлю триггер для создания тега и узел для добавления тега в группу тегов
Мы добавили следующее в workflows:
Я хочу поставить тег на тему, если она создана с определённым текстом. Есть ли способ использовать нижний регистр для {{ $JSON.topic.title }}, чтобы это выражение возвращало true для “pub run”, “Pub Run”, “pUb rUn”?
(фрагмент)
{
"id": "db9e2fa2-0008-4110-9c77-f1060124d7e7",
"type": "condition:if",
"typeVersion": "1.0",
"name": "If",
"parameters": {
"combinator": "and",
"conditions": [
{
"id": "29d3ed6c-e984-4d9b-83bf-861bd11b4b0a",
"operator": {
"type": "string",
"operation": "contains",
"singleValue": false
},
"leftValue": "={{ $json.topic.title }}",
"rightValue": "pub run"
}
]
},
ты пробовал {{ $JSON.topic.title.toLowerCase() }}?
спасибо — сработало!
какой язык шаблонов используется?
Похоже, это собственная система JavaScript-выражений Discourse Workflows, которая выполняется на стороне сервера в песочнице, а не отдельный язык шаблонов, такой как Liquid или Handlebars.
Например:
={{ $json.topic.title.toLowerCase() }}
работает, потому что содержимое {{ ... }} интерпретируется как JavaScript, а toLowerCase() — это стандартный метод строк в JavaScript.
Реализация находится в plugins/discourse-workflows/lib/discourse_workflows/expression_resolver.rb; она предоставляет глобальные переменные, специфичные для рабочих процессов, такие как $json, $input, $itemIndex, $trigger, $execution и $().
Синтаксис и концепции очень похожи на n8n. На самом деле в другом месте исходного кода Workflows есть явная ссылка на n8n:
в коммите ниже, который был добавлен через onebox, реализовано поведение объединения для merge-узла и включает тест с описанием:
defaults clash handling to add_suffix (matches n8n position combine)
Таким образом, есть доказательства того, что некоторые части Workflows намеренно соответствуют поведению n8n, хотя я не смог найти ничего, что явно указывало бы на то, что сам язык выражений скопирован из n8n или основан на нём. Поэтому я бы описал его как песочные JavaScript-выражения, предоставляемые Discourse Workflows, с некоторыми конвенциями, похожими на n8n.
Было бы супер круто иметь доступ к формам на основе групп ![]()
Я заметил, что для шага «AI Agent» требуется, чтобы у агента была включена функция Bot. Почему это необходимо? Возможно, это где-то задокументировано? Я потратил несколько минут, пытаясь понять, почему я не могу выбрать определённого агента в выпадающем списке ![]()