Skip to main content
D
17-Peridot
Dobi17-Peridot
17-Peridot
October 17, 2025
Question

Auto associate doesn't apply WTPart subtype defaults

  • October 17, 2025
  • 2 replies
  • 617 views

Version: Windchill 13.0

 

Use Case: Autoassociate preference is turned on and a custom class that extends DefaultAutoAssociatePartFinderCreator implements AutoAssociatePartFinderCreator runs to select the correct subtype based on Product context. Autoassociate created WTParts don't have the particular subtype defaults.


Description:

I customized the AutoAssociatePartFinderCreator class to look at the product context a CAD document is being checked into and based on the context selects the appropriate subtype of WTPart to auto associate. 

This works as expected and the correct WTPart subtype is associated on check in based on context name. 

 

However, the subtype defaults and cascading attribution I set up for that particular subtype doesn't carry over. Instead, it looks as though the WTPart subtype is created based on the default parent WTPart. 

 

When I create a new part in the context, it follows the WTPart subtype attributes and defaults I set up. 

 

Is there a way to have the auto-associated part use the defaults for that WTPart subtype??

2 replies

Catalina
CatalinaCommunity Manager
Community Moderator
October 24, 2025

Hi @Dobi 

Thank you for your question. 

Your post appears well documented but has not yet received any response. I am replying to raise awareness. Hopefully, another community member will be able to help.

Also, feel free to add any additional information you think might be relevant.

 

Best regards,

Catalina | PTC Community Moderator
M
MTH13-Aquamarine
13-Aquamarine
October 24, 2025

Hi Dobi,

There should be an issue with your custom code as the propagation of the com.ptc.windchill.uwgm.common.autoassociate.DefaultAutoAssociatePartFinderCreator#createNewWTPart is using com.ptc.windchill.uwgm.common.autoassociate.WTPartUtilities#createNewPart, which does the copy, is carrying the subtype attributes.

D
17-Peridot
Dobi17-PeridotAuthor
17-Peridot
October 24, 2025

@MTH I'm happy to admit that this is an issue with my code.

 

I followed this: CS135305.

 

I define some call outs for my particular subtypes as called out in Type and Attribute Management.

// WCTypeIdentifier defaultWCType = (WCTypeIdentifier) defaultType;
public static final String ONE_WTPART_TYPE = "com.something.www.oneWTPart";
public static final String TWO_WTPART_TYPE = "com.something.www.twoWTPart";

I then override the `createNewPart` bit:

// Set the appropriate part type based on product context
try {			
 if (containerName.contains("one")) {
 part.setTypeDefinitionReference(TypedUtilityServiceHelper.service.getTypeDefinitionReference(ONE_WTPART_TYPE));
			} else {
	part.setTypeDefinitionReference(TypedUtilityServiceHelper.service.getTypeDefinitionReference(TWO_WTPART_TYPE));
			}

 

Am I wrong in assuming that by specifying the subtype in this way would pull the parent WTPart template? 

D
17-Peridot
Dobi17-PeridotAuthor
17-Peridot
October 28, 2025

PTC tech support suggests this:

 

"Creating a WTPart using the API may not automatically apply the default attribute values defined in Type and Attribute Management. However, you can use the PersistableAdapter API to set these values manually, as described in CS135663".

 

I have a number of cascading attributes in this subtype and it seems kind of blah to have to redo all of that in the API... at the very least it renders the autoassociate customization moot because the end result is a different part type but all the same attribution as the part type I can create on autoassociate anyways without the customization. So I'm not convinced this is the way.

 

Terms & ConditionsCookie settingsAccessibility statement