How to hide parent object type but leave sub-type visible and Instantiable

[TomU]

Is it possible to hide a parent object type but leave the sub-type visible and instantiable?

I'm exploring the possibility of using sub-typed WT parts for a particular project I'm working on.  For testing I've created two different sub-types, both with unique attributes.  (We don't currently use WT parts for anything else.)  When I go to create a new part, both the original parent WT Part and my two sub-typed parts are visible.  I'd like to limit the selection to only my sub-typed parts and not display the parent type.  If I make the parent type not instantiable then the sub-types disappear.  Is there some other way to hide the parent type, or make it not instantiable, while still retaining the two sub-types?  Maybe something with OIRs???

[BjoernRueegg]

I would let the main type instantiable, otherwise you won't have sometimes problem with selecting it in the configuration. E.g. in the policy administration. You can't add any policy for wt.part.WTPart if it is not instantiable.

You have now two possilbilities.

Add another level eg.

WTPart

 |--DumyPart. ->not instantiable

    |--Layout

    |--...

Or you need to set all the policies for each subtype. It just depends on the use case.

[TomU]

Is there any way to specify what sub-type should be used via OIR?  I'm okay with only one sub-type being active per context, as long as doing this will hide the parent type.

[BjoernRueegg]

Normally you define an OIR for the WTPart. This is also valid for all subtypes.

Then you only create a OIR for the subtypes which have different settings, e.g. number generator, folder, etc. 

[mmeadows-3]

Great responses, just adding a little more nuance...

For site administrators, setting instantiation works great, under the following conditions…

A. If we set WTPart to non-instantiable, all children will inherit the attribute, and are disabled too.  So, we must explicitly enable instantiation on each subtype of WTPart that we want to use.

B. It is common to leverage parent object permissions to apply a default set of permissions to all subtypes.  However, if we disable instantiation of WTPart, it will not be available to us in the Domain Policies when assigning new permissions.  So, we must re-enable instantiation on WTPart long enough to define our parent object permissions.  Then we can disable instantiation again.

Mike’s OIRs option can be a fallback configuration for business administrators who don’t have site administrator access.  If you go this route, be sure to create appropriate OIRs for all WTPart subtypes you want to create.  Otherwise, they inherit the ‘broken’ life cycle from WTPart and none of them will be available for use.

[MikeLockwood]

I've done in this for a long time - make the root type not instantiable, and use only sub types. 

It's rare that you need to make the root type instantiable and easy to temporarily make that change.  Most often it's just a matter of Policy Administrator.

Both ACLs and OIRs can be set on the root type, with overrides as needed on the sub type - a very elegant and effective way to configure many things.

Note: An alternative is a bit messy and not so elegant but works. If you leave the root type instantiable but don't want users to be able to create it, configure an OIR on the root type with a lifecycle that doesn't exist. This removes that type from any drop-down.