Discourse ワークフロー

コミュニティワークフロー テンプレートの導入は予定されていますか?この素晴らしい実装に大きな価値をもたらすと私は考えています。

技術的な制約については詳しくありませんが、Discourse Discovery を利用してこの機能を有効/無効に切り替え、Discourse エコシステムとの接続を再利用できるのではないでしょうか。

トピックノードにあります。トピックを上げる(bump)操作が使用できます。

あ、見逃していました。おそらくアップデートが必要だったようです。ありがとうございます。

[Edit] アップデート後はすべて問題ありません。マニュアルでのBump(スレ立て)をしてくれて本当にありがとうございます :grinning_face:

「いいね!」 1

@j.jaffeux さん、こんにちは。トリガーに「新規ユーザー」を使用する場合、その新規ユーザーアカウントが有効化された場合のみ(新規ユーザーを登録するボットを除外するために)以下のアクションが実行されるようにしたいのですが、そのためにフィルタとして「承認済み」ステータスを使用する必要がありますか?よろしくお願いします。

また、上記の私の推測が正しい場合、TRUE値はどのように指定すればよいですか?「True」とするのか「T」とするのか?よろしくお願いします。

ついにうまく動いたようです!この機能は本当に嬉しいです

「いいね!」 3

user.approved をドラッグ&ドロップする代わりに、プレーンモードのままリストから user.approved を選択すると、以下が表示されるはずです:

以下のような設定は可能でしょうか?

トリガー:ステージングユーザーが特定のカテゴリに返信を投稿したとき

アクション:そのステージングユーザーが返信したトピックのイベントが自動的にクローズされる — 次の画像と同様に

いいえ、これにはいくつかの詳細が不足しています

ありがとうございます。このユースケースをサポートするために、Workflowsにはまだいくつかの詳細やデータポイントが不足しているということですか?

「いいね!」 1

ありがとうございます。そうしてみましたが、user.approvedフィルターでは、登録してアカウントを確認したユーザーがフィルタリングされないようです。

こんにちは。「サンプル固定データ」とは何か教えていただけますか?

「いいね!」 1

ワークフローを使って数時間試みているのですが、エラーが出力されずにはAIが動かないようです。AIモデルを変更して再度試みるかもしれません。

私が達成しようとしているのは、次のようなものです(最近の議論と非常に関連しています!):

  1. スケジューラーを1日1回実行する。
  2. 30〜365日間返信がない投稿を検索する。(Data Explorerを使用)
  3. トピックが要約されていない場合は要約を作成し、データテーブルに保存する。
  4. 要約と最後の投稿をAIに渡し、未解決の問題やフォローアップが必要な事項があるかどうかをAIに尋ねる。
  5. AIの判断(フォローアップ投稿が必要かどうか)を保存する。(データテーブル)
  6. AIで処理済みの投稿から1件を選択し、返信対象とする。
  7. ボットを使用してフォローアップ、更新、または問題が解決したかどうかを確認する返信を行う。

基本的には、古い投稿に対して、フォローアップ投稿が必要かもしれない場合に、ランダムな再エンゲージメントを図るワークフローを作ろうとしています。

何かアイデアはありませんか? Data Explorerを使って投稿を取得し、AIから要約を取得することはできました。しかし、データテーブルが動作せず、自動投稿の段階には至りませんでした。ただ、かなり近づいたつもりです。

私の考えでは、これを複数のワークフローに分割することです:

  • ワークフロー1:古い投稿を取得し、要約を作成する。(データテーブルに保存)
  • ワークフロー2:要約と最後の投稿を確認し、フォローアップ投稿を行うべきかどうかを判断する。(データテーブルに保存)
  • ワークフロー3:データテーブルを確認し、投稿すべき投稿を選択し、どのようなタイプの返信を行うべきかを決定し、ボットアカウントで返信を投稿する。

このプラグインの使い方を完全に把握しているわけではありませんが、このプラグインには大きな可能性があります!

「いいね!」 1

出力部分で、JSONデータを自分で定義できます。

「いいね!」 1

@j.jaffeux 上記の質問のフォローアップとして、Workflows に Event アクションを追加する PR を作成しました:

以下のアクションが追加されます:

  • Event → イベントを閉じる
  • Event → イベントを開く

このアクションはトピック ID を受け取り、トピックの最初の投稿からイベントを解決し、通常の投稿編集/Event 同期パスを通じてイベントを更新します。

元のユースケースの方向性は、以下でテストしました:

投稿が作成される → 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

イベント作成時に自動でアクションが実行される機能があったら嬉しいです。具体的には、イベント作成者がデフォルトで自動的に参加者として登録されるようにしてほしいです。そうすればあらゆるケースに対応でき、特に私の利用シーンにはぴったりだと思います!:grin:

「いいね!」 2

来週、イベント用のノードがあります

「いいね!」 4

はい、これは Workflows の Event 領域に自然に統合できると思います。

現在の PR(FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub )では、ワークフロービルダーに Event セクションを追加しました。PR 説明のスクリーンショットにあるように、現在その Event メニューを開くと、以下の 2 つの操作が表示されます。

  • イベントを閉じる
  • イベントを開く

この PR では、レビュー対象の変更範囲を限定するため、あえてこれら 2 つの操作のみを含めています。

ご提示の使用例では、同じ Event メニューに別の操作、例えば 出席を設定 / 参加者を追加 のようなものが追加できる可能性があります。これにより、ワークフローはイベント作成者をユーザーとして使用し、イベント作成時にその出席状態を 参加予定 に設定できます。

「作成者を自動的に登録する」ための特別なアクションを持つよりも、ユーザーと出席状態を一般的に選択できるように実装する方が適切だと考えます。

フォローアップとしてこれを確認してみます。おそらく現在の「イベントを開く/閉じる」PR に焦点を当てたままにするため、別の PR として進めることになるでしょう。

「いいね!」 1

上記の投稿をする前に、あなたの返信を確認していませんでした。

来週Eventノードがリリースされるとのことなので、CIでmainに対するテストだけに頼るのではなく、同じ領域に影響を与える他のオープンな discourse-events / WorkflowsのPRブランチに対して、現在のPRをローカルでテストしてみます。

実際の重複や競合が見つかった場合は、このトピックを煩雑にせず、関連するGitHub PRで報告します。

「いいね!」 1

これは、このユーザーが pm_tags_allowed_for_groups に含まれている必要があるためだと考えられます。エラーメッセージはもっと改善できるかもしれません… 改善します。

EDIT: FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub によって改善されます。

「いいね!」 5