Customizing Access Control For Packages
Objective
You want to customize the default roles, domain structure, or access control policy rules associated with Packages across all contexts.
Background
Before you can use packages within a context, you must first enable packages for that context. When you enables packages for a given context, the system loads a site-wide package template XML file. The package template file contains package specific roles that are applied to the container team, the default domain structure for packages, and package-related policies.
The default domain structure will create a Package domain specific to the current context. All packages created within the context, as well as all of the objects created within the packages (collections, folders, documents, links, and deliveries) will use this package domain by default. Out of the box, the package domain is Private. This means that it won't inherit any policies from the container's default domain.
Scope/Applicability/Assumptions
This guide assumes that you want to customize the default roles, domain structure, or access control policy rules associated with Packages across all contexts. You should be familiar with managing Packages, teams, and administering access control for Windchill business objects.
Intended Outcome
Customize the default roles, domain structure, or access control policy rules associated with Packages across all contexts.
Solution
Use the package template XML file to customize the default roles, domain structure, and access control policy rules associated with Packages across all contexts.
Prerequisite knowledge
To achieve this objective, you need to have an understanding of the following:
• Administering Packages
• Creating business XML files for templates
• Windchill team concepts
• Administering Domains and Policies
• Access Control
Solution Elements
|
Element
|
Type
|
Description
|
|
packageTemplate.xml
|
XML
|
The XML file that contains the roles, domain structure, and policies associated with Packages. This file is loaded when you enable packages for a context.
Location: <Windchill>/loadXMLFiles
|
|
packageSharedTeamTemplate
|
XML
|
The XML file that contains the shared team roles. This file is loaded in addition to the packageTemplate.xml file when you enable packages for a context that is using a shared team that isn’t extended.
Location: <Windchill>/loadXMLFiles
|
Procedure - Modifying Domain Structure
The packageTemplate.xml file supports customization of the roles, domain structure, and access control policy rules.
To modify the roles, refer to the
projectMember element described in
Creating Business XML Files for Context Templates for each context. To modify the domain structure, refer to the DomainStructure Element section. To modify the access control policy rules, refer to the Common AccessControlRule Element section.
If you modify the domain structure in the packageTemplate.xml file, you must update the Default Domain Path for Packages site-level preference. This is because the domain path must be the same in both places. The existence of the domain specified in the preference is used to determine if packages have been enabled for a context. It is also used to determine the default domain associated with a Package when it is created.
Limitations
The packageTemplate.xml applies to the entire site which means you cannot customize it for specific contexts or specific packages.
If you change the default domain path, you may have to enable packages again. If the domain already exists in a context, you won't be prompted to enable packages again.
If the context is using a shared team that isn't extended, the roles from packagedSharedTeamTemplate.xml will be used and the roles from packageTeam.xml will be ignored.
Sample Code
Examples of Usage in Windchill Code
Filename: <Windchill>/loadXMLfiles/packageTemplate.xml
Package Team Role:
<projectMember>
<Role roleType="PACKAGE MANAGER"/>
</projectMember>
Package Domain Structure:
Package Access Control Policy Rule:
Additional Resources
Other Related Windchill Documentation