Context and Domain Hierarchy Overview
Context types have the following established hierarchy:
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):
The actual domain structures are determined in part by whether an application context is created as a private context or a public context, or created using a shared team. The domain structure for the /Default domain in private contexts starts under the /Private domain in the organization context. The domain structure for the /Default domain in public contexts and contexts using a shared team starts under the /Default domain in the organization context.
To illustrate the domain structures for shared team, private, and public contexts, consider the following examples:
Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box library template) creates a public library context using the following:
The team is a local team.
The context is named Sales and is a child of the Bike Company context.
Then the domain hierarchy for the Sales library is as follows:
From within the Policy Administration utility, the hierarchy is shown as follows:
Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box product template) creates a product context using the following:
The team is a shared team named Design.
The context is named Tire and is a child of the Bike Company context.
Then the domain hierarchy for the Tire product is as follows:
From within the Policy Administration utility, the hierarchy is shown as follows:
Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box project template) creates a public project context using the following:
The team is a local team.
The context is named Super Bike and is a child of the Bike Company context.
Then the domain hierarchy for the Windchill ProjectLink Super Bike project is as follows:
From within the Policy Administration utility, the hierarchy is shown as follows:
Assume that the Windchill installation creates the site context and has a child organization context that is named Bike Company, and that an administrator (using an out-of-the-box project template) creates a private project context using the following:
The team is a local team.
The context is named Future Bike and is a child of the Bike Company context.
Then the domain hierarchy for the Windchill ProjectLink Future Bike project is as follows:
From within the Policy Administration utility, the hierarchy is shown as follows:
The domain hierarchy for the /Default domain in a product, library, project, or program depends on whether a shared team is used, or if a shared team is not used, on the Private Access selection. If a shared team is used, the Private Access selection is disabled. When creating a project (or program), the manager selects the Private Access option Project Members Only (or Program Members Only) to create a private project (or program) that uses a domain hierarchy branch that starts with /Private. Selecting any other Private Access option creates a public project (or program) that uses a domain hierarchy branch that starts with the /Default domain in the organization context.
When creating a product (or library), the manager selects Yes for the Private Access option to create a private product (or library) that uses a domain hierarchy branch that starts with /Private. Selecting No creates a public product (or library) that uses a domain hierarchy branch that starts with the /Default domain in the organization context.
The /Private domain in the organization context only contains an out-of-the-box policy rule granting access rights to the organization context administrators, which is why it is named /Private. The /Default domain and its child domains in the organization context have a set of out-of-the-box policy rules that provide access rights to a broader set of participants, and so application contexts inheriting from these domains are referred to as public contexts.
Было ли это полезно?