Планируется ли создать шаблон Community Workflow? Я думаю, что он может значительно повысить ценность этого замечательного решения.
Я не знаю о технических ограничениях, но мне кажется, что Discourse Discovery может включать/отключать эту функциональность и повторно использовать подключение к экосистеме Discourse.
Хорошо, я, наверное, просто не заметил, так как нужно обновить. Спасибо.
[Edit] После обновления всё в порядке, большое спасибо за этот ручной Bump 
Привет, @j.jaffeux. При использовании триггера «новый пользователь» я хотел бы, чтобы соответствующее действие выполнялось только в том случае, если аккаунт нового пользователя был активирован (чтобы исключить ботов, регистрирующих новых пользователей). Для этого мне нужно использовать статус «одобрен» (approved) в качестве фильтра? Спасибо.
И если моё предположение выше верно, как мне указать значение TRUE? В виде «True» или «T»? Спасибо?
Похоже, теперь всё-таки заработало! Очень рад этой функции
Вместо перетаскивания user.approved оставайтесь в обычном режиме и выберите user.approved в списке. Вы должны увидеть следующее:
Возможно ли настроить следующее:
триггер: ответ пользователя, чей пост был отложен, в определённой категории
действие: тема, в которой отложенному посту в которой пользователь ответил, закрывается автоматически — аналогично
Нет, нам не хватает нескольких деталей для этого
Спасибо! Вы имеете в виду, что в Workflows всё ещё не хватает некоторых деталей/данных для поддержки этого сценария?
Спасибо, я так и сделал, но фильтр user.approved, похоже, не фильтрует пользователей, которые зарегистрировались и подтвердили свой аккаунт.
Я уже несколько часов пытаюсь настроить что-то с помощью рабочих процессов. Не получается заставить ИИ работать без ошибок. Возможно, я попробую сменить модель ИИ и повторить.
Я пытаюсь добиться следующего (и это очень актуально для недавнего обсуждения!):
По сути, я просто пытаюсь создать рабочий процесс, который будет стимулировать повторное взаимодействие с устаревшими постами, но которые, возможно, требуют дополнительного ответа.
У кого-нибудь есть идеи? Я смог получить посты с помощью Data explorer и получить краткое содержание от ИИ. Не удалось заставить работать таблицы данных, и я не дошёл до этапа автоматической отправки. Но я был близок.
Я думал разделить это на несколько рабочих процессов:
Не уверен, правильно ли я всё понял в части использования, но этот плагин обладает большим потенциалом!
это в выводе, где вы можете самостоятельно определить данные в формате JSON
@j.jaffeux Продолжая мой вопрос выше, я открыл PR, в котором добавлено действие Event в Workflows:
Добавлено:
Действие принимает ID темы, находит событие по первому сообщению в теме и обновляет его через стандартный путь синхронизации редактирования сообщений/событий.
Я протестировал исходное направление использования сценария с помощью:
Создание сообщения → Событие / Закрыть событие
используя Input → topic.id.
Ответ на тему события закрывает само событие, оставляя тему открытой, и изменения сразу отображаются в интерфейсе.
PR включает покрытие unit/integration-тестами, и полный набор тестов discourse-events пройден: 1124 примера / 0 ошибок.
Это решает вопрос с действием Event в описанном выше сценарии. Условия по пользователю/категории/источнику email затем можно обрабатывать отдельно через триггер/условия workflow.
Есть ли советы по автоматическому тегированию ответов от ИИ-агента? Я пробую следующую схему, но она не определяет ответы от пользователя-агента.
Кстати, это скрытый тег, но агент находится в группе, у которой есть доступ к нему.
{
"id": "6",
"name": "My workflow",
"nodes": [
{
"id": "a8490306-e7e7-42e4-b909-851f3c4fbcba",
"type": "trigger:topic_created",
"typeVersion": "1.0",
"name": "When a new personal message is created",
"parameters": {
"topic_type": "personal_messages"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 178.6210678807947,
"y": -18.94519916824343
}
},
{
"id": "a80813a3-35cf-414e-98b8-9892f3eab496",
"type": "condition:filter",
"typeVersion": "1.0",
"name": "Keep PMs from Navigator",
"parameters": {
"combinator": "and",
"conditions": [
{
"id": "sender_is_navigator",
"operator": {
"type": "string",
"operation": "equals",
"singleValue": false
},
"leftValue": "={{ $json.post.username }}",
"rightValue": "Navigator"
}
]
},
"credentials": {},
"webhookId": null,
"position": {
"x": 290.515625,
"y": -18.281249999999993
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
},
{
"id": "acfcf305-1a04-4d2e-876c-48b015dc038c",
"type": "action:topic_tags",
"typeVersion": "1.0",
"name": "Add onboarding-initiated tag",
"parameters": {
"topic_id": "={{ $json.topic.id }}",
"operation": "add",
"tag_names": "onboarding-initiated",
"actor_username": "Navigator"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 513.1770833333333,
"y": -27.32031249999998
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
}
],
"connections": {
"Keep PMs from Navigator": {
"main": [
[
{
"node": "Add onboarding-initiated tag",
"type": "main",
"index": 0
}
]
]
},
"When a new personal message is created": {
"main": [
[
{
"node": "Keep PMs from Navigator",
"type": "main",
"index": 0
}
]
]
}
},
"settings": {},
"staticData": {},
"pinData": {},
"versionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"activeVersionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"versionCounter": 31
}
Я бы очень хотел, чтобы при создании события автоматически выполнялось действие: автор по умолчанию сразу же регистрировался на нём. Это позволило бы учесть все возможные ситуации, особенно в моём случае! 
у нас есть нода на мероприятие, которое состоится на следующей неделе
Да, я думаю, что это органично впишется в ту же область Event (События) в Workflows (Потоках работы).
В моём текущем PR, FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub, я добавил раздел Event в конструкторе потоков работы. На скриншоте в описании PR видно, что открытие этого меню Event пока предлагает две операции:
Это намеренно единственные две операции в этом PR, так как именно это является объёмом изменений, которые я пытаюсь получить на ревью.
Ваш случай использования потенциально может добавить ещё одну операцию в то же меню Event, например, Set attendance (Установить присутствие) / Add attendee (Добавить участника). Тогда поток работы мог бы использовать автора события в качестве пользователя и установить его присутствие как Going (Будет), когда событие создаётся.
Я думаю, что лучше реализовать это универсально — выбирая пользователя и состояние присутствия, — а не создавать специальное действие только для «автоматической регистрации автора».
Я посмотрю на это как на последующую задачу, вероятно, в виде отдельного PR, чтобы текущий PR по Open/Close Event остался сфокусированным.
Я не видел вашего ответа, прежде чем опубликовать свой выше.
Поскольку вы упомянули, что узел Event появится на следующей неделе, я также протестирую свой текущий PR локально против других открытых веток PR discourse-events / Workflows, которые затрагивают ту же область, а не буду полагаться только на CI против main.
Если я обнаружу какое-либо фактическое пересечение или конфликт, я сообщу об этом в соответствующем PR на GitHub, а не буду засорять эту тему.
Я думаю, это потому, что этот пользователь должен быть указан в pm_tags_allowed_for_groups. Можно сказать, что сообщение об ошибке могло быть более понятным… Я улучшу его.
P.S.: это будет исправлено в FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub