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

オントロジー ロール移行

オントロジー リソースの認可モデルがdatasource-derived permissionsからオントロジー ロールに変更されます。このドキュメントでは、移行のステップバイステップガイドを提供します。

オントロジー ロールはまだすべてのFoundryエンロールメントで一般に利用可能ではありませんが、2024年後半には利用可能になります。詳細については、Palantirの担当者にお問い合わせください。

オントロジー ロールとは?

  • オントロジー ロールは、オントロジー リソースの認可のための更新されたソリューションです。オントロジー ロールは、2024年にdatasource-derived permissionsに代わってデフォルトの認可モデルとなります。
  • オントロジー ロールは、オブジェクトタイプ、リンクタイプ、およびアクションタイプに適用され、これらは「オントロジー リソース」と呼ばれます。デフォルトでは、2023年9月以降に作成されたすべての新しいエンロールメントにオントロジー ロールの認可モデルが適用されます。共有プロパティタイプ、インターフェースなどの最新機能を使用するには、これらのロールを適用する必要があります。
  • オントロジー ロールを使用すると、各オントロジー リソースおよびそのメタデータに対してロールを直接付与できます。すべてのメタデータの権限は、Ontology Managerで管理されます。
  • データの権限は常にデータソースの権限によって管理されます。オントロジー ロールを使用すると、オブジェクトインスタンスやリンクインスタンスなどのリソースのデータをこれらのリソースから切り離すことができます。詳細はオントロジー権限をご覧ください。

定義

オントロジー ロールは、オントロジー リソースの認可のための更新されたソリューションであり、まもなくdatasource-derived permissionsに代わってデフォルトの認可モデルとなります。オントロジー ロールを使用すると、オブジェクトタイプ、リンクタイプ、およびアクションタイプなどの各オントロジー リソースおよびそのメタデータに対してロールを直接付与できます。この機能により、オントロジー リソースをオブジェクトインスタンスやリンクインスタンスなどのリソースのデータから切り離すことができます。

各オントロジーは、1つまたは複数のFoundry組織にリンクされています。

ロールの権限は、オントロジー ロールのドキュメントに詳細が記載されています。

ロールに移行されたすべてのオブジェクトタイプ、リンクタイプ、およびアクションタイプは、そのオントロジーにアクセスできるすべてのユーザーに表示権限を持ちます。したがって、オントロジーメタデータ情報は、そのオントロジーのすべてのユーザーがアクセス可能です。

オントロジー リソースをオントロジー ロールに移行するために明示的な順序は必要ありません。そのため、datasource-derived permissionsを使用するオブジェクトタイプと、オントロジー ロールを使用するオブジェクトタイプが混在することが可能です。この移行の目的のために、オブジェクトタイプを編集できると定義する内容は次のとおりです:

  • datasource-derived permissionsを使用するオブジェクトタイプ: ユーザーはそのオブジェクトタイプの入力データソースに対してEditor権限を持っています。
  • オントロジー ロールを使用するオブジェクトタイプ: ユーザーはオブジェクトタイプに対してOntology Editor権限を持ち、入力データソースに対する権限は必要ありません。これはオントロジー リソースおよびそのメタデータを編集する権限のみを付与し、データ/データソース自体には何の権限も付与しません。オブジェクトのデータ(メタデータではない)へのアクセスは、入力データソースで付与された権限によって引き続き管理されます。

オントロジー ロールに移行する

ユーザーのエンロールメントでオントロジー ロールが有効になっているが、所有するオントロジー リソースをロール認可モデルに移行していない場合、Ontology Managerに移行を促すバナーが表示されます。あるいは、オントロジー リソースのテーブルを閲覧して、「バックデータソースと同じ権限」を使用しているものをフィルター処理することもできます。

オントロジー ロールはまだすべてのFoundryエンロールメントで利用可能ではありません。オントロジー ロールにアクセスできない場合は、Palantirサポートにお問い合わせください。

前提条件

移行を実行するには、ユーザーは次の権限を持っている必要があります:

  1. Foundryオントロジーで変更を行う権限。

  2. 各個別リソースのための次の権限:

    • オブジェクトタイプの場合、ユーザーは入力データソースに対してOwner権限を持っている必要があります。
    • 1対多リンクタイプの場合、追加の権限は必要ありません。リンクタイプで参照される両方のオブジェクトタイプに対してViewer権限を持ち、リンクタイプ自体またはオントロジーレベルでOwnerである必要があります。
    • 多対多リンクタイプの場合、1対多リンクタイプに必要な権限に加えて、リンクタイプの入力データソースに対してOwner権限を持っている必要があります。
    • アクションタイプには追加の権限は必要ありません。

アクションタイプの変更には、オントロジー ロールに移行した後に追加の権限が必要です。アクションタイプを変更するには、アクションタイプが編集するオブジェクトタイプとアクションタイプ自体に対して権限が必要です。

移行の通知

オントロジー ロールへの移行は、Upgrade Assistantを通じて管理されます。専用のUpgrade Assistantタスクは、移行すべきオントロジー リソースのリストと、移行を実行する権限を持つ担当者を表示します。Upgrade Assistantからリソースを開くと、Ontology Managerアプリケーション内でリソースを移行するためのSecurityタブにユーザーが誘導されます。

ユーザーがオントロジー ロールを設定する権限を持っている場合、まだ移行されていないオントロジー リソースは、初めてオントロジー ロールを設定するための移行インターフェースにSecurityタブに表示されます。オントロジー リソースが移行されると、オントロジー ロールピッカーがSecurityタブに表示され、Ontology Ownersによって更新できます。

Ontology Managerアプリケーションを使用して移行する

オントロジー リソース(オブジェクトタイプ、アクションタイプ、リンクタイプ)をロールに移行する方法は2つあります:オントロジー リソースの一括移行またはすべてのオントロジー リソースの1つずつの移行

オントロジー リソースの一括移行

オントロジー リソースをロールに一括移行できます。続行する前に前提条件のリストを参照してください。一度に500個のリソースのみを移行できます。

一括移行するには、Ontology ManagerのAdvancedに移動し、Migrationsセクションのcontinue with migration assistantを選択します。

移行ウィザードが次のステップで表示されます。

  1. リソースの選択: 同じロールを適用したいすべてのオブジェクトタイプ、リンクタイプ、またはアクションタイプを選択します。下の画像は、移行ウィザードでリソースを選択するインターフェースを示しています:

bulk migration

  1. 関連リソース: 関連リソース(リンクタイプまたはアクションタイプ)が移行可能な場合にのみこのステップが表示されます。
  2. ロールの割り当て: グループ/ユーザーと、これらのオブジェクトタイプに割り当てたいデフォルトのロールを手動で設定できます。現在、ロール移行ツールは一括でロールを提案できません。ロールを付与する際には、ユーザーよりもユーザーグループを強くお勧めします。
  3. サマリー: サマリーを表示し、移行の影響を確認して、ロールを適用するために移行を完了します。

移行の影響を確認する際、バックデータソースから派生した以前の権限が新しく割り当てられたロール付与によって上書きされ、移行は元に戻せないことを認識することになります。

一括移行の例外

一部のアクションタイプは、さらに手順を踏まなければ一括移行できません。

アクションタイプは次の場合、ロールに移行できません:

  • アクションタイプに現在のユーザーの権限を確認する提出基準がない場合。
    • 解決策: Ontology ManagerのSecurity & Submission criteriaタブ(Submission criteriaセクション)で現在のユーザーに基づく条件を追加し、再度移行を試みる前にオントロジーに保存します。
  • アクションタイプが関数を利用している場合、移行前に@edits decoratorsで再発行する必要があります。
    • 解決策: decoratorsドキュメントの手順を参照してください。

これらの問題に対処するには、Action Typesページに移動し、Same permissions as backing datasourceでフィルター処理すると、問題のために移行されていないアクションタイプが表示されます。すべての未解決の問題を解決し、残りのアクションタイプの一括移行を再度実行します。

Warning

アクションタイプを移行する際には、アクションタイプがデプロイされているすべての使用ケースと参照されるオブジェクトタイプの両方に十分なコンテキストを持つユーザーにのみ権限が付与されることを確認してください。

すべてのオントロジー リソースの1つずつの移行

Ontology Managerのホームページから、移行したいオントロジー リソース(オブジェクトタイプ、リンクタイプ、またはアクションタイプ)を選択し、Security setupSame permissions as backing datasourcepermissionsownerでフィルター処理します。

移行するエンティティを選択し、ヘッダーのMigrate to rolesまたはSecurityタブのStart using rolesを選択します。

移行ウィザードが2つの推奨ロールオプションで表示されます:Datasource rolesOntology admins & datasource roles。これらのオプションにより、ユーザーは既存のオントロジー設定に合わせたロールを使用および設定できます。オプションの1つを選択すると、推奨ロールのリストが自動入力されます。これらのロールは後で変更できます。

  • Datasource roles: このオプションは、入力データソースにEditorまたはOwnerロールを持つすべてのユーザーおよびユーザーグループを追加します。
  • Ontology admins & datasource roles: このオプションは、datasource-derived permissionsに基づいて現在のオントロジー リソースを変更できるすべてのユーザーを追加します。これらのユーザーはOntology Administratorsユーザーグループに属し、入力データソースにEditorまたはOwnerロールを持っています。

下の画像は、移行ウィザードでのロールの提案を示しています:

migrating one resource roles suggestion

希望のロールの提案を選択し、推奨されるオントロジー ロールとオブジェクトタイプのデフォルトロールを確認し、必要に応じて変更します。次に、サマリーを表示し、影響を確認して、ロールを適用するために移行を完了します。

下の画像は、移行ウィザードでロールを割り当てる方法を示しています:

migrating one resource assign roles

例外

次の場合、アクションタイプをロールに移行しようとするときに移行が妨げられることがあります:

  • アクションタイプに現在のユーザーの権限を確認する提出基準がない場合。
    • 解決策: Ontology ManagerのSecurity & Submission criteriaタブ(Submission criteriaセクション)で現在のユーザーに基づく条件を追加し、再度移行を試みる前にオントロジーに保存します。
  • アクションタイプが関数を利用している場合、移行前に@edits decoratorsで再発行する必要があります。
    • 解決策: decoratorsドキュメントの手順を参照してください。

これらの問題が解決された場合、アクションタイプをロールに移行できるようになります。

不要になったオントロジー リソースがある場合はどうすればよいですか?

アクションを必要とする不要なオントロジー リソースがある場合は、Ontology cleanup toolを使用してリソースを削除できます。このツールは、データソースが削除された場合、非推奨日が過ぎた場合、インデックスが失敗している場合、オントロジー ロールを使用しているかどうかなどの一連の基準に基づいて削除しても安全なオブジェクトタイプを特定するのに役立ちます。

関数を利用したアクションタイプの移行

関数を利用したアクションタイプには、バックエンドの関数の移行が必要です。Foundryは関数を自動的に移行しようとしますが、場合によっては関数を手動で宣言する必要があります。移行後に関数を利用したアクションが失敗した場合、FAQセクションで詳細を確認してください。

移行に関するFAQ

オブジェクト対応のアプリケーションに変更はありますか?

ユーザーは、以前は入力データソースへのViewerアクセスがないために表示できなかったオブジェクトタイプおよびリンクタイプのメタデータにアクセスできるようになる場合があります。これは、入力データソースのデータにアクセスできることを意味するものではなく、これらのデータソースのロールによって常