Context and Domain Hierarchies
A context provides the framework from which user actions are executed. Projects, products, libraries, and organizations are examples of unique context types. For example, if an administrator accesses Windchill PDMLink and navigates to the Utilities page in the context of the Bike123 product and then opens the Policy Administration utility, the domains and policies available to the administrator are those in the context of the Bike123 product or those created in its ancestor domains.
An example of the established hierarchy of context types is as follows:
This example assumes that both Windchill PDMLink and Windchill ProjectLink are installed.
Installing a Windchill solution always creates the Site (root) context and can create a child organization context that is named during the installation. If the installation does not create an organization context, the administrator creates it as part of getting the solution set up for users. Additional organization contexts and contexts that are children of an organization context are created as required by your business practices.
The contexts that are available include the following:
• Administrators of Windchill PDMLink can create product, library, and organization contexts.
• Administrators of Windchill ProjectLink can create project, program, and organization contexts.
When each context is created, a set of domains is also created for use within the context. Generally, the domain hierarchy is established using the context hierarchy. A parent domain is either in the same context as its child domain or in the parent context of its child domain's context. In the following diagram, the site, organization, and library contexts are shown with one domain defined in each context. The domain hierarchy shows domain3 (in the library context) as a child of domain2 (in the organization context) and domain2 as a child of domain1 (in the Site context):
To illustrate this rule, consider the following examples:
1. Assume that Windchill PDMLink is installed and a child organization context named “Bike Company” is created under the Site context. An administrator (using an out-of-the-box library template and leaving the default selection for Private Access as No) creates a library context named Sales that is a child of the Bike Company context. The default domain hierarchy for this structure is displayed in the Domains pane of the Policy Administration utility as follows:
2. Assume that Windchill ProjectLink is installed and a child organization context named “Bike Company” is created under the Site context. An administrator creates a project context (using an out-of-the-box project template and setting Private Access to Project Members Only) named Super Bike that is a child of the Bike Company context. The default domain hierarchy for this structure is displayed in the Domains pane of the Policy Administration utility as follows:
When a shared team is created, the system creates a domain for setting access control policy rules for the shared team members. For details about this domain and other shared team information, see About Shared Teams.
For additional information regarding contexts, see Contexts – Distributed and Hierarchical Administration and Context and Domain Hierarchy Overview.
For information about accessing and creating context templates, see About Context Templates.