Рабочие процессы Discourse

Спасибо, это помогло!

3 лайка

@gilles Я уже реализовал последующее действие, о котором упоминал выше:

Оно добавляет универсальную операцию Событие → Установить посещаемость, которая включает:

  • участника
  • состояние посещаемости: Иду / Интересует / Не иду / Удалить посещаемость
  • ID темы
  • необязательного актора

Таким образом, ваш исходный сценарий можно реализовать следующим образом:

Создание поста → Если это первый пост → Событие / Установить посещаемость

используя автора события в качестве участника и устанавливая ему статус Иду.

Я протестировал именно этот шаблон локально в интерфейсе Workflows, наложив его на #42932, и подтвердил, что пользователь автоматически регистрируется как «Иду» на событии.

PR пока находится в статусе черновика, так как зависит от #42932. Как только #42932 будет объединён, я пересоберу его на основе main, что оставит только изменения, связанные с посещаемостью.

2 лайка

@Ethsim2 Спасибо, ты просто супер! :+1: :clap:

1 лайк

Существует ли способ повторить выполнение рабочего процесса (с тем же событием), аналогично тому, как можно повторно отправить загрузку (payload) через вебхук?

Нет, извините, мы пока это не поддерживаем

2 лайка

Существует ли триггер или событие, которое срабатывает при создании НОВОЙ метки?

Когда пользователь создаёт новую метку, можно ли автоматически добавить её в определённую группу меток? Если нет, какой подход рекомендуется?

1 лайк

Нет, у нас ничего из этого нет. Не могли бы вы подробнее описать ваш сценарий использования?

Можно ли сделать так, чтобы:

  1. он рассматривал все новые темы;
  2. сверял тег с уже существующими;
  3. если тег новый — <insert action>.
1 лайк

Существует событие «Изменение метки темы». Вы можете затем вызвать API Discourse и посмотреть, сколько раз используется данная метка. Если она встречается один раз / находится именно в этой теме, значит, метка новая.

Альтернативный, возможно, более простой вариант: настроить вебхук для события «метка создана» и указать его на триггер вебхука в workflow.

1 лайк

Сценарий: у меня есть группа тегов «artist» (исполнитель). Новые исполнители появляются постоянно, поэтому, когда пользователи создают новые теги, они автоматически появляются в системе. Я хочу, чтобы эти новые теги автоматически добавлялись в группу тегов «artist», а не добавлялись вручную. Есть ли хороший способ добиться этого с помощью Workflows?

Как вы можете быть уверены, что это тег исполнителя, а не какой-нибудь другой случайный тег?

Именно этим занимается этап с ИИ. Агент ИИ сначала определяет, относится ли новый тег к одной из заранее определённых групп (артист / участник / регион / тип события / тип релиза); если он не подходит ни к одной из них, тег пропускается и никогда не попадает в группу. Таким образом, случайные теги отфильтровываются, а только правильно классифицированные теги автоматически добавляются в группу тегов.

1 лайк

ок, добавлю триггер для создания тега и узел для добавления тега в группу тегов

4 лайка

Мы добавили следующее в workflows:

7 лайков

Я хочу поставить тег на тему, если она создана с определённым текстом. Есть ли способ использовать нижний регистр для {{ $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"
          }
        ]
      },

1 лайк

ты пробовал {{ $JSON.topic.title.toLowerCase() }}?

1 лайк

спасибо — сработало!

какой язык шаблонов используется?

Похоже, это собственная система 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.

3 лайка

Было бы супер круто иметь доступ к формам на основе групп :face_holding_back_tears:

2 лайка

Я заметил, что для шага «AI Agent» требуется, чтобы у агента была включена функция Bot. Почему это необходимо? Возможно, это где-то задокументировано? Я потратил несколько минут, пытаясь понять, почему я не могу выбрать определённого агента в выпадающем списке :sweat_smile:

1 лайк