サーバー構成 > アクセス制御リスト権限 > コンフィギュレーション管理の ACL > サブプロジェクト ACL
  
サブプロジェクト ACL
コンフィギュレーション管理のサブプロジェクトは、親プロジェクトに割り当てられた ACL エントリによって制御されます。個別のサブプロジェクトの権限が必要な場合、個別のサブプロジェクト ACL を設定する必要があります。サブプロジェクト ACL の設定は、ACL をコピーすることで非常に容易になります。
さらに、親プロジェクトの ACL に加えられた変更は、共有サブプロジェクト以外では、そのディレクトリに含まれる任意のサブプロジェクトに再帰的に適用されます。ただし、個々のサブプロジェクトに ACL を構成すると、親プロジェクトの ACL に加えられた変更はサブプロジェクト ACL には適用されません。したがって、作成された各サブプロジェクト ACL を個別に変更する必要があります。
* 
共有サブプロジェクトはその場所から共有される場所へ権限を継承しません。共有サブプロジェクトの権限は、サブプロジェクトが最初に作成された場所に基づいています。サブプロジェクトの情報を表示して、サブプロジェクトが最初に作成された場所に関する情報を参照できます。
プロジェクトにおいて権限が制限されている場合、共有プロジェクトの権限を調整してデータセキュリティが維持されていることを確認してください。
* 
共有サブプロジェクトを操作するとき、Windchill RV&S では、ACL を解決するために、プロジェクト階層内の相対的な名前ではなく、ファイルシステム内にあるサブプロジェクトの実際の名前を使用します。これにより、異なるプロジェクトをまたがる変更パッケージの可搬性が向上します。
デフォルトでは、親プロジェクトの ACL に対する変更はバリアント プロジェクトに再帰的に適用されません。
ポリシーの解決は、各ポリシーに割り当てられたロック属性に影響されます。ポリシーは上から下にチェックされ、ロックされたポリシーが検出されると、ポリシーはそれ以上チェックされなくなります。ポリシーが最上位プロジェクトでロックされている場合は、含まれているサブプロジェクト内のポリシーは使用されません。ポリシーをロックすると、より厳密なポリシーが優先されなくなります。ポリシーの操作の詳細については、コンフィギュレーション管理ポリシー オプションを参照してください。
継承された権限を操作する 1 つの方法として、サブプロジェクト ACL 内の特定の権限を消去する (未設定のままにする) 方法があります。こうすると、消去された権限は、常に親プロジェクトの ACL に基づいた許可または拒否の権限になります。この手法を利用すると、すべてのサブプロジェクトに効力を及ぼすために必要な親の変更は 1 つだけです。