커뮤니티 워크플로우 템플릿이 계획되어 있나요? 이 훌륭한 구현에 많은 가치를 더할 수 있다고 생각합니다.
기술적 한계를 정확히 알지는 못하지만, Discourse Discovery가 이 기능을 활성화/비활성화하고 Discourse 생태계와의 연결을 재사용할 수 있다고 생각합니다.
음, 업데이트가 필요해서 그런지 못 본 것 같아요. 감사합니다.
[Edit] 업데이트 후 모든 것이 정상적으로 작동합니다. 수동으로 올려주셔서 정말 감사합니다 
1개의 좋아요
@j.jaffeux 님, 안녕하세요. “새 사용자” 트리거를 사용할 때, 해당 새 사용자 계정이 활성화된 경우에만(봇이 생성한 새 사용자를 제외하기 위해) 다음 작업이 실행되기를 원합니다. 이를 위해 필터로 “승인됨(approved)” 상태를 사용해야 하나요? 감사합니다.
그리고 위의 제 가정이 맞다면, TRUE 값을 어떻게 지정해야 하나요? "True"로 해야 하나요, 아니면 "T"로 해야 하나요? 감사합니다.
드디어 제대로 작동하는 것 같습니다! 이 기능이 정말 좋습니다.
3개의 좋아요
다음과 같은 설정이 가능한가요?
트리거: 특정 사용자가 이메일을 통해 게시글을 올리는 경우 특정 카테고리에 대한 답변
액션: 특정 사용자가 이메일을 통해 게시글을 올리는 경우 해당 토픽의 이벤트가 자동으로 닫히도록 설정 — 다음 이미지와 유사하게
아니요, 이 작업에는 몇 가지 세부 사항이 빠져 있습니다.
감사합니다 - 이 사용 사례를 지원하기 위해 워크플로에 아직 몇 가지 세부 사항/데이터 포인트가 부족하다는 말씀이신가요?
1개의 좋아요
알겠습니다. 그렇게 해보았지만, user.approved 필터가 가입하고 계정을 확인한 사용자를 필터링하지 않는 것 같습니다.
워크플로우를 이용해 무언가를 구현하려고 몇 시간째 고군분투 중입니다. 에러가 뜨지 않고 AI를 작동시키는 방법을 좀체 찾지 못하겠네요. AI 모델을 변경한 뒤 다시 시도해 볼 생각입니다.
제가 이루고자 하는 목표는 다음과 같습니다. (최근 논의 내용과 매우 관련이 깊습니다!)
- 스케줄러가 하루에 한 번 실행됩니다.
- 30일에서 365일 동안 답글이 달리지 않은 게시물을 찾습니다. (데이터 탐색기 사용)
- 아직 요약되지 않은 주제를 요약하고 데이터 테이블에 저장합니다.
- 요약 내용과 마지막 게시물을 AI에게 전달하여, 미해결된 이슈나 후속 조치가 필요한 사항이 있는지 질문합니다.
- 후속 게시물이 필요한지 여부에 대한 AI의 판단을 저장합니다. (데이터 테이블)
- AI가 처리한 게시물 중 하나를 선택해 답글을 작성합니다.
- 봇을 통해 후속 업데이트를 요청하거나 이슈가 해결되었는지 묻는 답글을 게시합니다.
결국, 오래된 게시물 중 후속 조치가 필요한 것들에 대해 무작위 재관여(re-engagement)를 유도하는 워크플로우를 만들어 보려는 것입니다.
어떤 아이디어가 있으신 분 계신가요? 데이터 탐색기를 이용해 게시물을 가져오고 AI로부터 요약을 받는 것까지는 성공했습니다. 하지만 데이터 테이블은 작동하지 않았고, 자동 게시 단계까지 도달하지는 못했습니다. 그래도 꽤 근접한 상태입니다.
여러 개의 워크플로우로 나누는 것을 고려해 보았습니다:
- 첫 번째 워크플로우는 오래된 게시물을 가져와 요약을 작성합니다. (데이터 테이블에 저장)
- 두 번째 워크플로우는 요약과 마지막 게시물을 검토하여 후속 게시물이 필요한지 판단합니다. (데이터 테이블에 저장)
- 세 번째 워크플로우는 데이터 테이블을 확인하여 게시할 대상 게시물을 선택하고, 어떤 유형의 답글을 달아야 할지 결정하여 봇 계정으로 답글을 게시합니다.
이렇게 사용하는 것이 맞는지 확신이 서지 않지만, 이 플러그인은 엄청난 잠재력을 가지고 있습니다!
수정: 이 문제를 해결했고 해당 주제에 게시했습니다:
1개의 좋아요
직접 JSON 데이터를 정의할 수 있는 출력 부분에 있습니다
1개의 좋아요
@j.jaffeux 위의 제 질문에 대한 후속 내용으로, Workflows에 Event 작업을 추가하는 PR을 열었습니다:
추가되는 내용은 다음과 같습니다:
- Event → 이벤트 닫기
- Event → 이벤트 열기
해당 작업은 토픽 ID를 받아, 토픽의 첫 번째 게시글에서 이벤트를 식별한 후, 일반적인 게시글 수정/Event 동기화 경로를 통해 이벤트를 업데이트합니다.
원본 사용 사례의 방향을 다음과 같이 테스트했습니다:
게시글 생성 → Event / 이벤트 닫기
Input → topic.id를 사용했습니다.
이벤트 토픽에 답글을 달면 이벤트는 닫히되 토픽 자체는 열린 상태로 유지되며, 해당 변경 사항이 UI에 실시간으로 반영됩니다.
PR에는 단위/통합 테스트 커버리지가 포함되어 있으며, discourse-events 전체 스위트는 1,124개 예제 / 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개의 좋아요
이벤트를 생성할 때 자동으로 실행되는 기능이 있으면 좋겠습니다. 기본적으로 작성자가 해당 이벤트에 바로 등록되도록 하는 것이죠. 이렇게 하면 모든 상황에 대응할 수 있고, 특히 제 사용 사례에 완벽하게 맞을 것 같습니다! 
2개의 좋아요
다음 주에 이벤트 노드가 있습니다
4개의 좋아요
네, 이 기능이 워크플로의 이벤트 영역에 자연스럽게 통합될 수 있을 것 같습니다.
현재 작성 중인 PR(FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub)에서 워크플로우 빌더에 이벤트 섹션을 추가했습니다. PR 설명의 스크린샷에서 확인하듯, 현재 해당 이벤트 메뉴를 열면 두 가지 작업이 제공됩니다:
- 이벤트 닫기
- 이벤트 열기
해당 PR에서는 리뷰를 요청하려는 변경 사항의 범위를 명확히 하기 위해 고의로 이 두 작업만 포함했습니다.
사용자의 사용 사례는 동일한 이벤트 메뉴에 참석 상태 설정 또는 참가자 추가와 같은 또 다른 작업을 추가할 수 있습니다. 그러면 워크플로우가 이벤트 작성자를 사용자로 지정하고, 이벤트가 생성될 때 해당 사용자의 참석 상태를 **참석 예정(Going)**으로 설정할 수 있습니다.
특수한 경우(예: “작성자 자동 등록”)만을 위한 액션을 만드는 것보다, 사용자와 참석 상태를 선택할 수 있는 범용적인 방식으로 구현하는 것이 더 좋다고 생각합니다.
현재의 이벤트 열기/닫기 PR에 집중할 수 있도록, 후속 작업으로 별도의 PR을 통해 이 부분을 검토해 보겠습니다.
1개의 좋아요
위에서 제 답변을 올리기 전에 당신의 답변을 보지 못했습니다.
다음 주에 이벤트(Event) 노드가 추가될 것이라고 언급하셨으므로, 메인 브랜치를 대상으로 한 CI에만 의존하지 않고, 현재 제 PR을 로컬에서 동일한 영역을 다루는 다른 공개된 discourse-events / Workflows PR 브랜치들과 비교하여 테스트해 보겠습니다.
실제로 중복이나 충돌이 발견되면, 이 주제에 혼란을 주기보다는 관련 GitHub PR에 보고하겠습니다.
1개의 좋아요
이것은 해당 사용자가 pm_tags_allowed_for_groups에 포함되어야 하기 때문인 것 같습니다. 에러 메시지는 더 명확하게 개선할 수 있을 것 같네요… 개선하겠습니다.
수정: FIX: provides a better error when user can't tag PM - Pull Request #43019%EC%9D%84 - discourse/discourse - GitHub 통해 개선될 예정입니다.
5개의 좋아요