注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

Approvals

ユーザーが Foundry で特定の変更を行う権限を持っていない場合、その変更をリクエストする必要があります。このリクエストは承認を得るために管理者に送られます。必要な承認が得られるとリクエストが実行され、リクエストされた変更が適用されます。

Foundry で変更をリクエストし、承認し、実行するこのワークフローは、Approvals アプリケーションで管理されます。このアプリケーションには Foundry から直接アクセスできます。また、特定の管理ワークフローでは Control Panel からアクセスできます。Approvals はコンプライアンス、ガバナンス、ピアレビューワークフローを集約し、Foundry で簡単に管理できるようにします。承認を使用するワークフローの例として、プロジェクトアクセスリクエストやオントロジーの提案のレビューがあります。

プライバシーに関するベストプラクティスは、指定された担当者への説明責任が求められる、機密性の高い変更や重大な影響を及ぼす変更に承認ステップを使用することです。Approvals を使用してこれらの変更に対する人間の監督を維持するためのガイダンスについては、プライバシーと市民的自由の実践を確認してください。

基本概念

リクエストは1個以上のタスクで構成されます。すべてのリクエストは Approvals の受信トレイに表示されます。

Approvals の受信トレイ

Approvals の受信トレイでは、ユーザーが関連するリクエストを検索し、効率的に処理できます。ここでは、種類、作成者、ステータスなどの属性でリクエストを絞り込めます。

フィルターは左側のサイドバーにあります。ご自身のレビューを待っているリクエストを表示するには、自分の受信箱フィルターを選択します。ご自身が作成したリクエストを表示するには、自分が作成者フィルターを選択します。

承認の受信トレイ

リクエストは完了後も保存されるため、過去の判断の監査ログとして参照できます。

リクエスト

リクエストの例

リクエストにはタスクが含まれます。タスクを実行してリクエストされた変更を適用するには、タスクがすべて承認される必要があります。Approvals アプリケーションの受信トレイには、リクエストの一覧が表示されます。

リクエストは、次のいずれかの状態になります。

  • 承認待ち: リクエストを実行するために承認が必要なタスクを含む、未完了のリクエストです。
  • 完了: 実行されずに終了したリクエストです。終了したリクエストを再開することはできません。リクエストが不要になった場合、権限を持つユーザーはそのリクエストを終了できます。
  • 拒否済みかつ完了: レビュー担当者によって拒否され、実行されずに終了したリクエストです。このリクエストを再開することはできません。
  • 変更リクエスト済み: レビュー担当者が変更を要求したリクエストです。リクエストは未完了のままとなり、権限を持つユーザーは、必要な変更に対応するためにリクエストを編集したり、追加の理由を提示したりできます。
  • アクションが必要: すべてのタスクが承認されていますが、ユーザーによる何らかの操作がなければ実行できないリクエストです。たとえば、リクエストが承認されていても、必要な Checkpoint が完了していない場合、Checkpoint が送信されるまでリクエストを実行できません。
  • 完了: すべてのタスクが承認されたために実行されたリクエストです。

リクエストのアクション

リクエストは、リクエストしたユーザーまたはレビュー権限を持つ担当者が編集または終了できます。リクエストを承認、拒否、または拒否して終了できるのは、レビュー権限を持つ担当者のみです。

リクエストに複数のタスクが含まれ、レビュー権限を持つ担当者がタスクごとに異なる場合、レビュー担当者によるアクションは、その担当者がレビュー権限を持つタスクにのみ適用されます。アクションはリクエスト単位でのみ実行でき、それに応じてタスクに適用されます。

リクエストのアクション

タスク

2個のタスクを持つレビュー担当者

タスクは、Foundry での個別の変更です。リクエストを実行してリクエストされた変更を適用するには、リクエストに関連するすべてのタスクが承認される必要があります。タスクの例を次に示します。

  • グループメンバーシップ: ユーザーをグループのメンバーとして追加します。グループに対する権限の管理権限またはメンバーシップの管理権限、あるいはその両方を持つ管理者が、このタスクを承認できます。
  • プロジェクトアクセスリクエスト: ユーザーにプロジェクトのロールを直接付与します。プロジェクトの所有者ロールを持つユーザーが、このタスクを承認できます。
  • マーキングアクセスリクエスト: ユーザーをマーキングのメンバーとして追加します。このマーキングに対する権限の管理権限を持つ管理者が、このタスクを承認できます。
  • 参照の追加リクエスト:プロジェクトへの参照を追加します。プロジェクトの編集者または所有者ロールを持つユーザーが、このタスクを承認できます。
  • オントロジーの提案:オントロジーを変更します。このタスクから Ontology Manager にリダイレクトされ、提案された変更の詳細を確認できます。オントロジーの所有者ロールを持つ管理者が、このタスクを承認できます。

タスクはライフサイクルを通じて、次の状態に移行します。

  • レビュー: タスクの要件が満たされておらず、レビュー権限を持つ担当者によるレビューを待っている状態です。新しく作成されたリクエストのタスクは、デフォルトでこの状態になります。
  • 承認済み: タスクのすべての要件が満たされ、必要な承認が得られた状態です。
  • 拒否済み: レビュー権限を持つ担当者がタスクを拒否した状態です。これは、レビュー担当者が「拒否して終了」または「変更リクエスト済み」アクションを実行したときに発生します。リクエストが終了していない場合、レビュー権限を持つ担当者はこのタスクに戻り、承認によって最初の拒否をオーバーライドできます。

同じリクエスト内でも、タスクごとにレビュー権限を持つ担当者が異なる場合があるため、以下に示すように、同じリクエスト内のタスクが異なる状態になることがあります。リクエストを実行するには、すべてのタスクが承認される必要があります。

一部が承認されたリクエスト

必須の Checkpoint

特定のアクション(たとえば、グループへのユーザーの追加)に Checkpoint が設定されている場合、関連するリクエストには理由の提示も必要になります。

対応するタスクには、Checkpoint が完了しているかどうかが表示されます。通常、リクエストしたユーザーは、リクエスト時に Checkpoint を完了する必要があります。完了していない場合、レビュー権限を持つ担当者が、リクエストしたユーザーに代わって Checkpoint を完了できます。

必須および完了した Checkpoint

通知

リクエストのライフサイクルのさまざまな時点で、リクエストしたユーザーとレビュー担当者に、メールまたは Foundry 内で通知が送られます。プラットフォームの通知設定は、アカウント > 設定 > 通知で行います。次の Approvals の通知を設定できます。

  • レビュー担当者として追加しました: リクエストのレビュー担当者として追加されたことを知らせます。通知は、リクエストが最初に作成されたときに送られます。グループのメンバーであることによってリクエストのレビュー担当者に追加された場合、そのグループのメンバーが50人未満の場合にのみ通知が送られます。これは、大規模なグループへの通知送信を避けるためです。ユーザーが手動でレビュー担当者として追加したときにも通知が送られます。
  • 呼び出しに成功しました: レビューしたリクエストの実行に成功したことを知らせます。
  • リクエストは終了しました: ご自身が作成したリクエスト、またはレビュー担当者となっていたリクエストが終了したことを知らせます。
  • リクエストが作成されました: リクエストを作成したことを知らせます。
  • レビュー担当者のナッジ: まだレビューが必要なリクエストについて、ナッジが送られたことを知らせます。

通知