役割とグループについて
以下のトピックでは、コンテキストチーム内での役割とグループの使用について説明します。
役割
役割は、アプリケーションコンテキストのメンバーをそのコンテキスト内で管理される情報およびアクティビティに関連付けます。役割は、コンテキスト内で類似する職務を持つユーザーをチームで論理的に分類するのに役立ちます。コンテキストマネージャは、アプリケーションコンテキストのメンバーになるようにユーザーに依頼する際、各ユーザーにデザイナー、レビュー担当者などの役割を少なくとも 1 つ割り当てる必要があります。コンテキスト内のメンバーを複数の役割に割り当てることもできます。各メンバーに割り当てられた一連の役割は、メンバーテーブルに表示されます。
一部の役割やグループは組織とアプリケーションコンテキストが作成される際に作成されますが、コンテキストが共有チームを使用していないか使用中の共有チームがローカルに拡張できるものであれば、「メンバー」テーブルから各コンテキストに追加の役割を定義することもできます。
コンテキストマネージャ役割は、アプリケーションコンテキストの作成と編成、チームメンバーへの参加要請とメンバーの除去、およびコンテキストの操作の管理などの特別な権限を持ちます。プロジェクトまたはプログラムのコンテキストでは、コンテキストマネージャ役割でもプロジェクトまたはプログラムのトラッキング情報を管理します。
コンテキストの作成者には、自動的にコンテキストマネージャ役割が割り当てられます。アプリケーションコンテキストの管理を共有するため、コンテキストマネージャはほかのメンバーをコンテキストマネージャ役割に割り当てることができます。使用可能なコンテキストマネージャ役割は以下のとおりです。
• プロジェクトコンテキスト -- プロジェクトマネージャ
• プログラムコンテキスト -- プログラムマネージャ
• 製品コンテキスト -- 製品マネージャ
• ライブラリコンテキスト -- ライブラリマネージャ
ゲスト役割を使用すると、実際にメンバーとして参加要請されなくてもアプリケーションコンテキストを表示できます。以下のアクセス許可は、特定のコンテキストのゲスト役割に割り当てられている参加者に適用されます。
• コンテキストへの参加要請の電子メールが配布されません。
• リンクまたは検索結果によってコンテキストにアクセスできます。
• フォルダまたはオブジェクト特有のアクセスコントロールから明示的に排除されている場合を除いて、コンテキストのコンテンツにアクセスできます。
 |
電子メールアドレスなしで Windchill ソリューションに追加したユーザーは、ユーザーやグループをチームへ追加する際に返される検索結果に表示されません。
|
役割を使用してアプリケーションコンテキストの情報へのアクセスを管理できます。各役割は、役割と同じ名前を持つシステムグループに関連付けられています。「ポリシー管理」ユーティリティを使用すると、コンテキストマネージャまたは管理者として、システムグループごとにポリシーアクセス制御規則を設定できます。さらに、オブジェクトのオーナーとして「アクセス制御を編集」操作を使用して、そのオブジェクトに対するアクセス許可を付与または除去することができます。たとえば、新しいファイルがアップロードされたり、新しいフォルダや部品が作成された場合、その情報へのアクセスの設定は、オブジェクトの作成者が担当します。
|
|
役割に関連したシステムグループによってアクセスを設定する以外に、次にこのトピックで説明するその他のシステムグループを使用してもアクセスを設定できます。
|
各 Windchill ソリューションで使用可能な役割や設定可能なアクセス許可の詳細については、アクセス制御の概要を参照してください。
グループ
グループは、情報へのアクセス制御管理、操作の表示制限、電子メール通信へのアクセス、およびミーティングへの参加要請のために使用されます。たとえば、ミーティングへの参加者はグループごとに参加要請したり電子メールで資料を送付することができます。
組織コンテキスおよびサイトコンテキスト内で作成と管理が可能なユーザー定義のグループやエンタープライズディレクトリサーバーを経由して作成と管理が可能なグループ以外に、コンテキストチームを使用したシステムグループもあります。システムグループは、チーム役割メンバーシップを管理するために使用され、Windchill データベースでのみ管理されます。このセクションではチームを使用したシステムグループについて説明します。Windchill で作成できるユーザー定義グループの詳細については、グループ (組織)または新規グループの作成を参照してください。
コンテキストチームまたはチームテンプレートで定義されている各役割には、対応するシステムグループが同じ名前で自動的に作成されます。たとえば、変更管理者 II 役割のシステム役割グループは「変更管理者Ⅱ」であり、メンバー役割のシステム役割グループは「メンバー」です。役割に追加されるユーザーは、対応するシステムグループに自動的に追加されます。次に、コンテキストマネージャは、「ポリシー管理」ユーティリティを使用して、システムグループのアクセスポリシーを作成できます。役割が使用されるたびに、ポリシーが適用されます。
コンテキストチームを使用するために以下のグループが追加で作成されます。
• チームメンバーグループにはアプリケーションコンテキスト内のすべてのチームメンバーが含まれます。このグループは各アプリケーションコンテキスト内で作成されます。このグループは Windchill が管理しますので、グループのメンバーシップを手動で変更しないでください。
このグループが「チームメンバー」と表示される場合と、teamMembers と表示される場合があります。
• コンテキストチーム内のメンバーの組織を表現する一連のシステムグループ。各グループには、1 つの組織内で特定のアプリケーションコンテキストに属するメンバーがすべて含まれています。チームメンバーが追加および除去されると、そのチームの組織グループは自動的に更新されます。新規組織のユーザーがコンテキストに追加されると、その組織のメンバーを受け入れるシステムグループが自動的に作成されます。各システムグループの名前は組織の名前と同じになります。この一連のグループは Windchill が管理するので、グループのメンバーシップを手動で変更しないでください。
チームの組織グループは組織名を使用して表示されたり、xxxx_ORG と表示されたりします。xxxx は、組織に関連付けられている内部番号です。
たとえば、アプリケーションコンテキストが作成され、企業 A のユーザーがコンテキストチーム内で使用可能な役割のメンバーとしてチームに追加されたとします。この操作によって以下のシステムグループが作成されます。
• チームメンバーグループ: 企業 A のメンバーを含む参加要請されたチームメンバーがすべて含まれます。
• 企業 A グループ: 企業 A のチームメンバーのみが含まれます。
その後、企業 B にコンテキストへの参加を要請するとします。これで、企業 B のチームメンバーはすべてチームメンバーグループに追加され、企業 B と名づけられた追加のグループが作成されます。このグループには企業 B のチームメンバーのみが含まれます。
|
|
ゲスト役割を使用してユーザーをチームに追加すると、このユーザーはチームのメンバーではないので、チームメンバーグループにも、コンテキスト内のメンバー組織を表す一連のシステムグループにも追加されません。ゲスト役割ユーザーはチームテンプレートの一部にすぎないので、ゲスト役割のユーザーはチームメンバーグループに自動的に追加されません。
|
また、組織コンテキストおよびサイトコンテキストにアクセス制御ポリシー規則を作成するとき、ポリシー管理ユーティリティでダイナミック役割を使用することもできます。ダイナミック役割は、コンテキストチームごとに管理されるコンテキストチームと組織グループを表します。たとえば、アクセス制御ポリシー規則の作成時に「役割」タブに表示される「コンテキストチーム役割: エンジニア」役割は、コンテキストチームと共有チームに関連付けられたエンジニアシステムグループを表します。ダイナミック役割に対して作成した規則は、その規則を作成した組織コンテキストの子コンテキストに継承されます。アプリケーションコンテキストで使用されるドメインの親ドメインに規則を作成する必要があります。ダイナミック役割の使用の詳細については、ダイナミック役割を使用したアクセス制御規則の集中管理を参照してください。