Patrick,
Is below what you are seeing? A picture (or many) is worth a thousand
words. I think I understand your issue and would have grasped it faster had
I seen your screen. If the TSE was stuck on this, their training failed
them.
If yes, to achieve what you are after: you have to implement a role or group
that is allowed to create these (only) and define it at default domain of
site, org, or container. Subdomains are only for activities AFTER the object
is created as wizard type picker does not look at the OIR folder.id
configuration to check access control rules. The form processor of the
wizard might, but therein lies your race condition. In short words, it
doesn't work the way you think it should, so this is not a zinger, just
typical Windchill conundrums.
If you only want this soft typed CN of content in that particular folder,
you can grant modify on the folder; deny everyone else; principal is the
same group or role granted create permission for the WTChangeOrder2, but for
the subfolder, within its assigned subdomain.
At the higher levels, grant create permission on a type basis to specific
roles if multiple CN's need to co-exist.
If a user is not in the role, they cannot create it and it usually doesn't
show up in type picker for them, if somehow an ACL winds up violating this
by conflict or other conundrum, the modify for the role/principal will
reject or permit to folder.id basis defined and constrained (ideally) within
OIR.
Adding some screens for you to confirm as you didn't share any:
OIR assuming other settings are inherited from composite OIR:
<attributevalues objtype="wt.change2.WTChangeOrder2">
<attrvalue id="folder.id"<br"/>algorithm="com.ptc.core.foundation.folder.server.impl.FolderPathAttributeAlg
orithm">
<arg>/Default/My CN Folder Restricted Create</arg>
</attrvalue>
</attributevalues>
This is not new to 10.x.
Good luck,
David
