#承認

#はじめに

「承認」は、人の手によって開始され、人の手によって処理されることで、関連データのステータスを決定するプロセスの一種です。これは通常、オフィスオートメーションやその他の手動による意思決定業務のプロセス管理に利用されます。例えば、「休暇申請」や「経費精算承認」、「原材料購入承認」といったシナリオにおける手動プロセスを作成・管理できます。

承認プラグインは、専用のワークフロータイプ（トリガー）である「承認（イベント）」と、このプロセス専用の「承認」ノードを提供しています。NocoBase独自のカスタムコレクションやカスタムブロックと組み合わせることで、様々な承認シナリオを迅速かつ柔軟に作成・管理できます。

#ワークフローの作成

ワークフローを作成する際に「承認」タイプを選択すると、承認ワークフローを作成できます。

その後、ワークフロー設定画面でトリガーをクリックすると、詳細設定用のダイアログが開きます。

#トリガーの設定

#コレクションのバインド

NocoBaseの承認プラグインは柔軟性を重視して設計されており、任意のカスタムコレクションと組み合わせて使用できます。つまり、承認設定でデータモデルを再設定する必要はなく、既存のコレクションを直接再利用できるのです。そのため、トリガー設定に入ったら、まずコレクションを選択し、どのコレクションのデータが作成または更新されたときにこのワークフローがトリガーされるかを決定します。

次に、対応するコレクションのデータ作成（または編集）フォームで、このワークフローを送信ボタンにバインドします。

その後、ユーザーがこのフォームを送信すると、対応する承認ワークフローがトリガーされます。送信されたデータは、対応するコレクションに保存されるだけでなく、承認フロー内にスナップショットとして保存され、後続の承認者が確認できるようになります。

#撤回

承認プロセスで申請者が撤回を許可されている場合、申請者インターフェースの設定で「撤回」ボタンを有効にする必要があります。

有効にすると、このプロセスで開始された承認は、どの承認者も処理する前であれば申請者によって撤回できます。ただし、後続の承認ノードで設定された承認者が処理を完了した後は、撤回できなくなります。

#承認申請フォームのインターフェース設定

最後に、申請者のフォームインターフェースを設定する必要があります。このインターフェースは、承認センターブロックから申請する場合や、ユーザーが撤回後に再申請する場合の送信操作に使用されます。「設定」ボタンをクリックしてダイアログを開きます。

申請者用のインターフェースには、バインドされたコレクションに基づく入力フォームや、ヒントやガイダンスとして機能する説明文（Markdown）を追加できます。フォームは必須です。追加しない場合、申請者はこのインターフェースに入っても操作できません。

フォームブロックを追加した後、通常のフォーム設定インターフェースと同様に、対応するコレクションのフィールドコンポーネントを追加し、フォームに入力する内容を整理するために自由に配置できます。

直接送信するボタンとは別に、「下書き保存」操作ボタンを追加して、一時保存の処理フローをサポートすることもできます。

#承認ノード

承認ワークフローでは、承認者が申請された承認を処理（承認、却下、または差し戻し）するための操作ロジックを設定するために、専用の「承認」ノードを使用する必要があります。「承認」ノードは承認プロセスでのみ使用できます。詳細については、承認ノードを参照してください。

#承認申請の設定

承認ワークフローを設定して有効にした後、対応するコレクションのフォームの送信ボタンにそのワークフローをバインドすることで、ユーザーが送信時に承認を申請できるようにします。

ワークフローをバインドすると、ユーザーが現在のフォームを送信したときに承認が申請されます。

#To-Doセンター

To-Doセンターは、ユーザーがTo-Doタスクを確認・処理するための統一された入り口を提供します。現在のユーザーが申請した承認や保留中のタスクは、上部のツールバーにあるTo-Doセンターからアクセスでき、左側のカテゴリナビゲーションを通じて異なる種類のTo-Doタスクを確認できます。

#申請済み

#申請済みの承認を確認

#新しい承認を直接申請

#自分のTo-Do

#To-Doリスト

#To-Doの詳細

#HTTP API

#申請者

#コレクションからの申請

データブロックから申請する場合、次のように呼び出すことができます（postsコレクションの作成ボタンを例に説明します）。

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post."
  }'
  "http://localhost:3000/api/posts:create?triggerWorkflows=workflowKey"

ここで、URLパラメータ triggerWorkflows はワークフローのキーであり、複数のワークフローはカンマで区切られます。このキーは、ワークフローキャンバス上部のワークフロー名にマウスカーソルを合わせると取得できます。

呼び出しが成功すると、対応するpostsコレクションの承認ワークフローがトリガーされます。

この操作で1対1のリレーションデータ（1対多は現在サポートされていません）のイベントをトリガーする必要がある場合、パラメータで ! を使用して、リレーションフィールドのトリガーデータを指定できます。

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post.",
    "category": {
      "title": "Test category"
    }
  }'
  "http://localhost:3000/api/posts:create?triggerWorkflows=workflowKey!category"

上記の呼び出しが成功すると、対応するcategoriesコレクションの承認イベントがトリガーされます。

#承認センターからの申請

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "collectionName": "<collection name>",
    "workflowId": <workflow id>,
    "data": { "<field>": "<value>" },
    "status": <initial approval status>,
  }'
  "http://localhost:3000/api/approvals:create"

パラメータ

• collectionName：承認申請の対象となるコレクション名です。必須。
• workflowId：承認申請に使用するワークフローIDです。必須。
• data：承認申請時に作成されるコレクションレコードのフィールドです。必須。
• status：承認申請時に作成されるレコードのステータスです。必須。選択可能な値は以下の通りです。
  • 0：下書き。保存はされますが、承認のために送信はされません。
  • 1：承認申請。申請者が承認リクエストを送信し、承認プロセスに入ります。

#保存と送信

申請中（または撤回済み）の承認が下書き状態の場合、以下のAPIを通じて再度保存または送信できます。

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "data": { "<field>": "<value>" },
    "status": 2
  }'
  "http://localhost:3000/api/approvals:update/<approval id>"

#申請済みの承認リストを取得

curl -X GET -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' \
  "http://localhost:3000/api/approvals:listMine"

#撤回

申請者は、以下のAPIを通じて現在承認中のレコードを撤回できます。

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  "http://localhost:3000/api/approvals:withdraw/<approval id>"

パラメータ

• <approval id>：撤回する承認レコードのIDです。必須。

#承認者

承認ワークフローが承認ノードに入ると、現在の承認者に対してTo-Doタスクが作成されます。承認者は、インターフェース操作またはHTTP API呼び出しを通じて承認タスクを完了できます。

#承認処理レコードの取得

To-Doタスクは承認処理レコードです。以下のAPIを通じて、現在のユーザーのすべての承認処理レコードを取得できます。

curl -X GET -H 'Authorization: Bearer <your token>' \
  "http://localhost:3000/api/approvalRecords:listMine"

ここで、approvalRecords はコレクションリソースとして、filter、sort、pageSize、pageなどの一般的なクエリ条件も使用できます。

#個別の承認処理レコードを取得

curl -X GET -H 'Authorization: Bearer <your token>' \
  "http://localhost:3000/api/approvalRecords:get/<record id>"

#承認と却下

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "status": 2,
    "comment": "Looks good to me.",
    "data": { "<field to modify>": "<value>" }
  }'
  "http://localhost:3000/api/approvalRecords:submit/<record id>"

パラメータ

• <record id>：承認処理するレコードのIDです。必須。
• status：承認処理のステータスです。2は「承認」、-1は「却下」を意味します。必須。
• comment：承認処理の備考情報です。任意。
• data：承認後、現在の承認ノードにあるコレクションレコードに対して行われる変更を示します。任意（承認時のみ有効）。

#差し戻し v1.9.0+

v1.9.0より前のバージョンでは、差し戻しは「承認」や「却下」と同じインターフェースを使用し、"status": 1が差し戻しを表していました。

v1.9.0以降、差し戻しには個別のAPIが用意されています。

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "returnToNodeKey": "<node key>",
  }'
  "http://localhost:3000/api/approvalRecords:return/<record id>"

パラメータ

• <record id>：承認処理するレコードのIDです。必須。
• returnToNodeKey：差し戻し先のターゲットノードのキーです。任意。ノードに差し戻し可能なノード範囲が設定されている場合、このパラメータを使用してどのノードに差し戻しるかを指定できます。設定されていない場合、このパラメータは渡す必要はなく、デフォルトで開始点に差し戻しされ、申請者が再提出します。

#委任

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "assignee": <user id>,
  }'
  "http://localhost:3000/api/approvalRecords:delegate/<record id>"

パラメータ

• <record id>：承認処理するレコードのIDです。必須。
• assignee：委任するユーザーのIDです。必須。

#承認者の追加

curl -X POST -H 'Authorization: Bearer <your token>' -d \
  '{
    "assignees": [<user id>],
    "order": <order>,
  }'
  "http://localhost:3000/api/approvalRecords:add/<record id>"

パラメータ

• <record id>：承認処理するレコードのIDです。必須。
• assignees：承認者として追加するユーザーIDのリストです。必須。
• order：承認者として追加する順序です。-1は「自分」より前、1は「自分」より後を示します。