Hiérarchies de contextes et de domaines
Le contexte constitue un cadre à partir duquel les actions des utilisateurs sont exécutées. Projets, produits, bibliothèques et organisations sont des exemples de types de contexte unique. Par exemple, si un administrateur accède à Windchill PDMLink et affiche la page Utilitaires dans le contexte du produit Vélo123, puis qu'il ouvre l'utilitaire Administration des politiques, les domaines et politiques accessibles à l'administrateur sont ceux qui figurent dans le contexte du produit Vélo123 ou ceux créés dans ses domaines ancêtres.
Exemple de la hiérarchie établie des types de contexte :
Cet exemple suppose que Windchill PDMLink et Windchill ProjectLink sont installés.
L'installation d'une solution Windchill crée le contexte Site (racine) et éventuellement un contexte d'organisation enfant qui reçoit un nom au cours de l'installation. Si l'installation ne crée pas de contexte d'organisation, l'administrateur doit créer ce dernier lors de la configuration de la solution pour les utilisateurs. D'autres contextes d'organisation et contextes enfants d'un contexte d'organisation peuvent être créés en fonction de vos pratiques.
Les contextes disponibles sont les suivants :
• Les administrateurs de Windchill PDMLink peuvent créer des contextes de produit, de bibliothèque et d'organisation.
• Les administrateurs de Windchill ProjectLink peuvent créer des contextes de projet, de programme et d'organisation.
Lors de la création de chaque contexte, un ensemble de domaines est également créé pour être utilisé dans le cadre du contexte. La hiérarchie des domaines est généralement établie sur la base de la hiérarchie des contextes. Un domaine parent se trouve soit dans le même contexte que son domaine enfant soit dans le contexte parent du contexte de son domaine enfant. Le schéma suivant présente les contextes de site, d'organisation et de bibliothèque avec un domaine défini dans chaque contexte. La hiérarchie de domaines montre que le domaine3 (dans le contexte de bibliothèque) est enfant du domaine2 (dans le contexte d'organisation) et le domaine2 est enfant du domaine1 (dans le contexte Site) :
Pour illustrer cette règle, examinons les exemples ci-après :
1. Supposons que Windchill PDMLink soit installé et qu'un contexte d'organisation enfant nommé "Fabricant de vélos" soit créé sous le contexte Site. Un administrateur (utilisant un modèle de bibliothèque prêt à l'emploi et conservant la sélection par défaut de l'option Accès privé sur Non) crée un contexte de bibliothèque nommé Ventes qui est un enfant du contexte Fabricant de vélos. La hiérarchie des domaines par défaut de cette structure s'affiche dans le volet Domaines de l'utilitaire Administration des politiques comme suit :
2. Supposons que Windchill ProjectLink soit installé et qu'un contexte d'organisation enfant nommé "Fabricant de vélos" soit créé sous le contexte Site. Un administrateur crée un contexte de projet (utilisant un modèle de projet prêt à l'emploi et le paramètre Accès privé défini sur Membres du projet uniquement) nommé Super Vélo qui est un enfant du contexte Fabricant de vélos. La hiérarchie des domaines par défaut de cette structure s'affiche dans le volet Domaines de l'utilitaire Administration des politiques comme suit :
Lorsqu'une équipe partagée est créée, le système crée un domaine pour définir les règles de contrôle d'accès des membres de cette équipe. Pour plus d'informations sur ce domaine et l'équipe partagée, consultez la rubrique d'aide A propos des équipes partagées.
Pour plus d'informations sur les contextes, consultez les rubriques Contexts – Distributed and Hierarchical Administration et Context and Domain Hierarchy Overview.
Pour plus d'informations sur l'accès aux modèles de contextes et à leur création, reportez-vous à la rubrique A propos des modèles de contexte.