Enable Subtype

[bwilson-2]

Thanks,

[MarcHendrickson]

You must disable at the context level and enable at the context level. This will allow you to create only what you want at the context level.

[bwilson-2]

Marc,
Thanks for the info. I guess that is the real question. How can I disable or enable a subtype in a particular context? I know that I can enable the ref document and use access control rule to limit its creation but that will be a lot of work especially since I only want the ref document enabled in one context. I will have to write a access control rule to limit its creation in all of my other contexts.

Thanks,
Brian

[cid:image001.gif@01CB6625.A4BF3A90]

Brian Wilson
SENIOR APPLICATION ENGINEER

[MikeLockwood]

Not positive but I believe that making a type instantiable or not is not applicable by context.

It's a very common need (desire) to constraint what sub type(s) can be created in any given Product or Library. All of the PTC Help info, examples, training, demo's, etc. have a very long list of Document types available to users and rely on users correctly selecting from the list.

The way we've approached this exact situation for many years is not all that elegant and is somewhat laborious, but works like a charm once set up. It may be possible to do this also via ACL's but we haven't found a robust way to do so.


* Enable all sub types that users need to be able to create anywhere

* In each context where you do not want certain sub types to be created, create a OIR with just the Lifecycle element - specifying a lifecycle that doesn't exist. We label these as "Prevent" OIRs.

o If in any context there is only one remaining type, then the drop-down for type selection disappears and the user has no choice. This is the situation we have for many special-purpose libraries in which only one document type can be created.

examples[cid:image002.png@01CF7E3D.B78B0580]
[cid:image003.png@01CF7E3D.B78B0580]

[bellj]

Use specific permissions for each context.
Create policy rules to allow creation, modifying, etc. of a X type in A context and other rules for Y type in B context.

joe bell
GSIMS Administrator
GPS Sustainment Information Management System
719-572-2890
bellj@gpssims.com<">mailto:bellj@gpssims.com>

[bwilson-2]

Joseph,
Thanks I was trying to avoid having to create the access rules but I guess that is what we need to do.

Brian

[cid:image001.gif@01CB6625.A4BF3A90]

Brian Wilson
SENIOR APPLICATION ENGINEER

[bwilson-2]

Mike,
Thanks for the information. This just might do the trick. I should be able to use this technique or use ACL's to do what I need to do.

Thanks,
Brian

[cid:image001.gif@01CB6625.A4BF3A90]

Brian Wilson
SENIOR APPLICATION ENGINEER

[MikeLockwood]

PTC really should consider providing a systematic way to address this. Ideal in my mind would be a simple checkmark by context for each sub type.

The need continually comes up.

For now, we've had the best luck with this approach - after spending lots of hour attempting to get same with ACLs.

[patrickchin2000]

Mike L. right with Type Manager being Org or Site level. It's all about Policy Administration at context level. Don't grant anything even team member role. You will have to remove the standard OOTB access to WTDocuments which is top level. For the context with subtype on, just add access to only the subtype and not top Document Master. For disabling the subtype, put a deny on the subtype but allow create Document Master.

Try that,

Patrick

In Reply to Brian Wilson:

Thanks,