#承認

#紹介

承認は、人手で開始し、人手で処理することで関連データのステータスを決定する、専用のプロセス形式です。通常、オフィスオートメーションやその他の人手による意思決定事項のプロセス管理に使用されます。例えば、「休暇申請」、「経費精算承認」、「原材料調達承認」などのシナリオの人手プロセスを作成・管理できます。

承認プラグインは、専用のワークフロータイプ（トリガー）「承認（イベント）」と、そのプロセス専用の「承認」ノードを提供します。NocoBase 特有のカスタムデータテーブルやカスタムブロックと組み合わせることで、さまざまな承認シナリオを迅速かつ柔軟に作成・管理できます。

#ワークフローの作成

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

その後、ワークフロー設定画面でトリガーをクリックしてダイアログを開き、詳細な設定を行います。

#トリガーの設定

#データテーブルのバインド

NocoBase の承認プラグインは柔軟な設計に基づいており、任意のカスタムデータテーブルと組み合わせて使用できます。つまり、承認設定でデータモデルを再設定する必要はなく、作成済みのデータテーブルを直接再利用します。そのため、トリガー設定に入った後、まずデータテーブルを選択し、このプロセスがどのデータテーブルのデータに対して承認を行うかを決定する必要があります。

#トリガー方式

業務データに対して承認を開始する際、以下の 2 つのトリガー方式を選択できます。

• データ保存前

  提出されたデータが保存される前に承認を開始します。承認が通過した後にデータを保存する必要があるシナリオに適しています。このモードでは、承認開始時のデータは一時データであり、承認が通過した後にのみ対応するデータテーブルに正式に保存されます。

• データ保存後

  提出されたデータが保存された後に承認を開始します。データを先に保存してから承認を行うシナリオに適しています。このモードでは、承認開始時にデータはすでに対応するデータテーブルに保存されており、承認プロセス中の修正も保存されます。

#承認を開始する場所

システム内で承認を開始する場所を選択できます。

• データブロック内でのみ開始

  そのテーブルの任意のフォームブロックのアクションをこのワークフローにバインドして承認を開始し、単一データの承認ブロックで承認プロセスを処理・追跡できます。通常、業務データに適しています。

• データブロックと待機センターの両方で開始可能

  データブロックに加えて、グローバルな待機センターでも承認の開始と処理が可能です。これは通常、管理データに適しています。

#承認を開始できるユーザー

ユーザー範囲に基づいた権限を設定し、どのユーザーがその承認を開始できるかを決定できます。

• すべてのユーザー

  システム内のすべてのユーザーがその承認を開始できます。

• 選択されたユーザーのみ

  指定された範囲のユーザーのみがその承認を開始できます。複数選択が可能です。

  

#承認開始のフォームインターフェース設定

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

申請者用のインターフェースには、バインドされたデータテーブルに基づいた入力フォームや、ヒントやガイドのための説明文（Markdown）を追加できます。フォームの追加は必須です。追加しない場合、申請者がこのインターフェースに入った後に操作できなくなります。

フォームブロックを追加した後、通常のフォーム設定インターフェースと同様に、対応するデータテーブルのフィールドコンポーネントを追加し、自由に配置してフォームの内容を構成できます。

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

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

有効にすると、このワークフローで開始された承認は、いずれかの承認者が処理する前であれば申請者によって撤回できます。ただし、後続の承認ノードで設定された承認者が処理した後は、撤回できなくなります。

#「マイ申請」カード 2.0+

待機センターの「マイ申請」リスト内のタスクカードを設定するために使用します。

カードには、表示したい業務フィールド（リレーションフィールドを除く）や承認関連情報を自由に設定できます。

承認申請が作成されると、待機センターのリストでカスタマイズされたタスクカードを確認できます。

#プロセス内のレコード表示モード

• スナップショット

  承認プロセスにおいて、申請者と承認者がアクセスした時点でのレコードの状態が表示されます。提出後は自分が修正したレコードのみが表示され、他の人がその後に行った更新は表示されません。

• 最新

  承認プロセスにおいて、申請者と承認者はプロセス全体を通じて常にレコードの最新バージョンが表示されます。操作前のレコードの状態に関わらず、プロセス終了後はレコードの最終バージョンが表示されます。

#承認ノード

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

#承認開始の設定

承認ワークフローを設定して有効にした後、そのワークフローを対応するデータテーブルのフォーム提出ボタンにバインドすることで、ユーザーが提出時に承認を開始できるようにします。

その後、ユーザーがそのフォームを提出すると、対応する承認ワークフローがトリガーされます。提出されたデータは対応するデータテーブルに保存されるだけでなく、承認フロー内にスナップショットとして保存され、後続の承認者が閲覧するために使用されます。

#待機センター

待機センターは、ユーザーが待機タスクを確認および処理するための統一された入口を提供します。現在のユーザーが開始した承認や待機中のタスクは、トップツールバーの待機センターからアクセスでき、左側のカテゴリナビゲーションで異なる種類の待機タスクを確認できます。

#マイ申請

#申請済みの承認を確認

#新しい承認を直接開始

#マイ待機

#待機リスト

#待機詳細

#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 はワークフローの key であり、複数のワークフローはカンマで区切ります。この key は、ワークフローキャンバス上部のワークフロー名にマウスホバーすると取得できます。

呼び出しに成功すると、対応する posts テーブルの承認ワークフローがトリガーされます。

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

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：下書き。保存するが承認を提出しません。
  • 2：承認を提出。申請者が承認申請を提出し、承認プロセスに入ります。

#保存と提出

開始（または撤回）された承認が下書き状態の場合、以下のインターフェースで再度保存または提出できます。

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"

#撤回

申請者は以下のインターフェースで、現在承認中のレコードを撤回できます。

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

パラメータ

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

#承認者

承認プロセスが承認ノードに入ると、現在の承認者に対して待機タスクが作成されます。承認者はインターフェースの操作で承認タスクを完了することも、HTTP 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 以降、差し戻しには専用のインターフェースがあります。

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

パラメータ

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

#転署

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 は「自分」の後を表します。