是否计划提供社区工作流模板？我认为这可以为这个出色的实现方案增添很多价值。
我不清楚具体的技术限制，但我认为 Discourse Discovery 可以启用或禁用此功能，并复用与 Discourse 生态系统的连接。
哦，我之前没注意到，可能是因为我需要更新一下，谢谢。
[编辑] 更新后一切正常，非常感谢你手动顶帖 
1 个赞
嗨 @j.jaffeux，当使用“新用户”触发器时，我希望以下操作仅在该新用户账户已激活的情况下执行（以排除注册新用户的机器人）。为此，我是否必须使用“已批准”状态作为筛选条件？谢谢。
如果我的上述假设是正确的，我该如何指定 TRUE 值？是写为 “True” 还是 “T”？谢谢？
看来现在确实起作用了！我非常喜欢这个功能。
3 个赞
不，我们还缺少一些细节。
谢谢——你的意思是，工作流中目前还缺少一些细节或数据点来支持这个用例吗？
1 个赞
谢谢，我已经这样做了，但 user.approved 过滤器似乎并没有过滤出已注册并确认账户的用户。
我尝试用工作流实现某个功能已经好几个小时了。AI 似乎总是报错，无法正常工作。我可能会换个 AI 模型再试一次。
我想实现的目标大致如下：（这也与最近的讨论非常相关！）
- 调度器每天运行一次。
- 查找过去 30 到 365 天内没有任何回复的帖子。（使用数据浏览器）
- 如果主题尚未被总结，则对其进行总结 + 存储到数据表中。
- 将总结 + 最后一条帖子提供给 AI，询问 AI 是否存在未解决的问题或需要跟进的内容。
- 存储 AI 的判断结果，即是否需要发布跟进帖。（数据表）
- 从 AI 处理过的帖子中选取一个进行回复。
- 使用机器人账号回复，询问跟进、更新情况，或确认问题是否已解决。
基本上，我只是想创建一个工作流，尝试在那些已经沉寂但可能需要跟进的帖子上引发一些随机互动。
大家有什么想法吗？我可以用数据浏览器获取帖子，也能让 AI 生成总结。但我没能成功让数据表工作，也没能走到自动发帖那一步。不过我已经取得了一些进展。
我的想法是将其拆分为几个工作流：
- 一个工作流获取旧帖子并撰写总结。（存储在数据表中）
- 另一个工作流审查总结和最后一条帖子，以判断是否应该发布跟进帖。（存储在数据表中）
- 再一个工作流查看数据表，选择应该发布跟进帖的帖子，确定回复类型，并使用机器人账号发布回复。
我不确定我是否完全理清了如何使用它，但这个插件潜力巨大！
1 个赞
它就在输出部分，你可以在那里自行定义 JSON 数据
1 个赞
@j.jaffeux 跟进一下我上面的问题，我已经提交了一个 PR，为 Workflows 添加了 Event 操作：
该 PR 添加了以下内容：
- Event → 关闭活动
- Event → 打开活动
该操作接收一个主题 ID，从主题的第一篇帖子中解析出活动，并通过常规的帖子编辑/活动同步路径更新该活动。
我已针对该用例的原始方向进行了测试：
创建帖子 → Event / 关闭活动
使用的是 Input → topic.id。
对活动主题的回复会关闭该活动，同时保持主题本身处于打开状态，且更改会在 UI 中实时显示。
该 PR 包含单元测试和集成测试覆盖，完整的 discourse-events 测试套件已通过，共 1124 个用例 / 0 个失败。
这解决了我上面提到的用例中 Event 操作的部分。用户/分类/邮件来源条件随后可以通过工作流触发器/条件单独处理。
2 个赞
有什么关于自动为 AI 代理回复打标签的技巧吗？我正在尝试以下工作流，但它无法捕获来自代理用户的回复。
顺便说一下，这是一个隐藏标签，但该代理所在的群组可以查看此标签。
{
"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
}
1 个赞
我非常希望能在创建事件时添加一个自动操作：默认将创建者直接加入该事件。这样就能适应所有情况，尤其非常适合我的使用场景！
1 个赞
我们下周有一个节点活动
4 个赞
是的，我认为这可以自然地融入工作流（Workflows）中同一个**事件（Event）**区域。
在我当前的 PR（FEATURE: Add event actions to workflows - Pull Request #42932%EF%BC%89%E4%B8%AD%EF%BC%8C%E6%88%91%E5%9C%A8%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%9E%84%E5%BB%BA%E5%99%A8%E9%87%8C%E6%B7%BB%E5%8A%A0%E4%BA%86%E4%B8%80%E4%B8%AA**%E4%BA%8B%E4%BB%B6**%E9%83%A8%E5%88%86%E3%80%82%E5%9C%A8 - discourse/discourse - GitHub PR 描述中的截图中，打开该事件菜单目前会显示两个操作：
- 关闭事件
- 开启事件
这些操作在该 PR 中是刻意只保留这两个的，因为这就是我正在寻求审查的变更范围。
你的用例可能会向同一个事件菜单中添加另一个操作，例如设置出席状态或添加参与者。这样，工作流就可以使用事件作者作为用户，并在事件创建时将他们的出席状态设置为参加（Going）。
我认为以通用方式实现会更好——即选择用户和出席状态——而不是有一个专门用于“自动注册作者”的特殊操作。
我会作为后续工作来研究这个问题，可能会作为一个单独的 PR 提交，以便当前关于开启/关闭事件的 PR 保持聚焦。
1 个赞
我在发布上面的回复之前没有看到你的回复。
既然你提到下周会发布一个 Event 节点，我会在本地将当前的 PR 与其他涉及相同区域的已打开的 discourse-events / Workflows PR 分支进行测试，而不仅仅依赖针对 main 分支的 CI。
如果发现任何实际的重叠或冲突，我会在相关的 GitHub PR 中报告，而不是让这个话题变得杂乱。
1 个赞
我认为这是因为该用户需要被包含在 pm_tags_allowed_for_groups 中，当然，这个错误提示可以做得更友好一些……我会对其进行改进。
编辑：将通过 FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub 进行改进。
5 个赞