Approvals

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

Foundry でのリクエスト、承認、実行のワークフローは Approvals アプリケーションによって管理されます。このアプリケーションは Foundry 内で直接アクセスするか、特定の管理ワークフローのために Control Panel でアクセスできます。Approvals はコンプライアンス、ガバナンス、およびピアレビューのワークフローを統合し、Foundry での管理を容易にします。Approvals を使用するワークフローの例としては、Project access requests および Ontology proposals があります。

コアコンセプト

Requests は 1 つまたは複数の tasks で構成されます。すべてのリクエストは Approvals inbox にリストされます。

Approvals inbox

Approvals inbox では、ユーザーが効率的にリクエストを検索できます。ここでは、タイプ、作成者、ステータスなどの属性でリクエストをフィルター処理することができます。

フィルターは左のサイドバーにあります。ユーザーのレビューを待っているリクエストを表示するには、Your inbox フィルターを選択します。ユーザーが作成したリクエストを表示するには、Created by you フィルターを選択します。

リクエストは完了しても保持されるため、過去の決定の監査ログとして参照することができます。

Requests

リクエストには、要求された変更を適用するために すべて 承認される必要があるタスクのセットが含まれています。Approvals アプリケーションでは、inbox はリクエストのリストです。

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

• Pending approval: 承認が必要なタスクを含むオープンリクエスト。承認されるとリクエストが実行されます。
• Closed: 実行されずにクローズされたリクエスト。クローズされたリクエストは再オープンできません。関係なくなったリクエストは適格なユーザーがクローズできます。
• Rejected and Closed: レビューアーによって拒否され、実行されずにクローズされたリクエスト。リクエストは再オープンできません。
• Changes requested: レビューアーが変更を要求したリクエスト。リクエストはオープンのまま、適格なユーザーが編集したり、必要な変更に応じてさらに説明を提供したりできます。
• Action required: すべてのタスクの承認が得られているが、ユーザーのアクションが必要なリクエスト。たとえば、リクエストが承認されているが、必要な checkpoints が完了していない場合、チェックポイントが提出されるまでリクエストは実行されません。
• Completed: すべてのタスクが承認され、実行されたリクエスト。

リクエストアクション

リクエストは、リクエストしたユーザーまたは適格なレビューアーによって編集またはクローズできます。適格なレビューアーのみがリクエストを approve、reject、または reject and close できます。

リクエストに複数のタスクがあり、異なる適格なレビューアーがいる場合、レビューアーのアクションはレビューする資格のあるタスクにのみ適用されます。アクションはリクエストレベルでのみ実行され、タスクに応じて適用されます。

Tasks

タスクは Foundry 内の個々の変更です。リクエストに関連する すべて のタスクが承認されて初めてリクエストが実行され、要求された変更が適用されます。タスクの例としては次のようなものがあります。

• Group membership: ユーザーを グループ のメンバーとして追加します。このタスクは、Manage permissions および/または Manage membership 権限を持つ管理者によって承認されます。
• Project access request: ユーザーに Project のロール を直接付与します。Project の Owner ロールを持つユーザーがこのタスクを承認できます。
• Marking access request: ユーザーを マーキング のメンバーとして追加します。このマーキングに Manage permissions を持つ管理者がこのタスクを承認できます。
• Add reference request: Project にリファレンス を追加します。Project の Editor または Owner ロールを持つユーザーがこのタスクを承認できます。
• Ontology proposal: オントロジー に変更を加えます。このタスクは Ontology Manager にリダイレクトされ、提案された変更の詳細が表示されます。オントロジーの Owner ロールを持つ管理者がこのタスクを承認できます。

タスクは異なる状態を経て進行します。

• Review: タスクの要件が満たされておらず、適格なレビューアーを待っています。これは新しく作成されたリクエストのデフォルト状態です。
• Approved: タスクのすべての要件が満たされ、必要な承認が得られました。
• Rejected: タスクが適格なレビューアーによって拒否されました。これは、レビューアーが Reject and close または Changes requested アクションを実行した場合に発生します。リクエストがクローズされていない場合、適格なレビューアーがこのタスクに戻り、最初の拒否を承認で上書きすることができます。

同じリクエスト内でタスクには異なる適格なレビューアーがいる場合があるため、同じリクエスト内の異なるタスクは異なる状態になることがあります。すべてのタスクが承認されるとリクエストが実行されます。

必須チェックポイント

特定のアクション（たとえば、ユーザーをグループに追加するため）に checkpoints が設定されている場合、関連するリクエストには正当な理由が必要です。

対応するタスクにはチェックポイントが完了しているかどうかが表示されます。通常、リクエストが作成されたときに、リクエストしたユーザーがチェックポイントを完了する必要があります。それが行われない場合、適格なレビューアーがリクエストしたユーザーに代わってチェックポイントを完了することができます。

通知

リクエスターおよびレビューアーは、リクエストライフサイクルの異なる時点でメールまたは Foundry 内で通知されます。プラットフォームの通知設定は Account > Settings > Notifications で設定できます。以下の Approvals 通知は設定可能です。

• Added as reviewer: ユーザーがリクエストのレビューアーとして追加されました。通知はリクエストが最初に作成されたときに行われます。ユーザーが グループ のメンバーシップのためにリクエストのレビューアーとして追加された場合、そのグループのメンバーが 50 人未満である場合にのみ通知されます。これは、大規模なグループへの通知を避けるためです。通知は、ユーザーが 手動でレビューアーとして追加された 場合にも行われます。
• Invocation succeeded: ユーザーがレビューしたリクエストが正常に実行されました。
• Request closed: ユーザーが作成したリクエストまたはユーザーがレビューアーであったリクエストがクローズされました。
• Request created: ユーザーがリクエストを作成しました。
• Reviewer nudge: まだレビューが必要なリクエストのために促されました。