Customizing Access Control For Packages

You want to customize the default roles, domain structure, or access control policy rules associated with Packages across all contexts.

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.

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.

Customize the default roles, domain structure, or access control policy rules associated with Packages across all contexts.

Use the package template XML file to customize the default roles, domain structure, and access control policy rules associated with Packages across all contexts.

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

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.

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.

<OrgStructure>
<DomainStructure>
<domainLevel>
<parentDomain>private</parentDomain>
<domainName>package</domainName>
<description>The default domain for packages.</description>
</domainLevel>
</DomainStructure>
</OrgStructure>

<AccessControlRule>
<domainName>package</domainName>
<externalTypeId>WCTYPE|wt.fc.WTObject</externalTypeId>
<lifecycleState>ALL</lifecycleState>
<WTPrincipleReference isInternal="true">
<groupName>PACKAGE MANAGER<groupName>
<groupType>ALL</groudType>
</WTPrincipleReference>
<grantPermissionSet>
<AccessPermissionSet>
<permissionField name="ALL"/>
</AccessPermissionSet>
</grantPermissionSet>
</AccessControlRule>