Restrict particular document type in other context

[dchopade-2]

Hello All,

We have one new document type. This document type need to be created in
libraries which are created using specific library template and this newly
created document type should not appear in any of the other contexts. How
this can be achieved ?



Regards,
Dipak

[MikeLockwood]

We've put quite a lot of effort into this exact situation over time.

All of PTC's examples and training show many document types; all are available for users to create in every context. Many businesses set things up such that (these are almost the same but not quite):

- Each doc type should only be allowed to be created in one or a few contexts

- Each context should only be allowed to have one or a few doc types created in it

There is no easy way provided PTC to accomplish this but there is a workaround (which some ongoing effort) which we have had in place for years that fully accomplishes this.

The workaround is to use OIRs in each context that specify for a specific doc sub type a lifecycle that doesn't exist for all doc types that you do not want to allow to be created in that context. We name all these OIRs with the doc subtype and the word "prevent." If you prevent all but one doc sub type in any given context, the drop down list of types disappears on the new Doc wizard and the only remaining allowed type is filled in and not editable. This also then allows only templates of that type to be selected. In each of these prevent OIRs we only include a single element: the lifecycle template (name = NoSuchLifecycle).

We have this use in special-purpose libraries for

- patent data,

- what we call "controlled lists and tables"

- best practices and guidelines for using Windchill and CAD

- many others

In the general Product contexts, these special doc types are prevented.

One you have this concept in mind, it greatly facilitates having different lifecycles, revision series, etc. for each doc sub type. Pretty difficult to do that without this approach.

[Avinash]

I think it can be acheived using access controlled policies (ACLs).

Provide deny access to SoftType in context/container where its not applicable

Or

Provide deny access at level where this Object is defined (Site/Org) and provide Create/modify/etc access in desired context/container.

Regards,

Avinash

[pwilliams-3]

I agree. There is no need for complex OIRs.

Thanks,
Patrick Williams

On Apr 11, 2014, at 12:29 PM, "Avinash Kor" <-<<a style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="mailto:-">>">mailto:->> wrote:


I think it can be acheived using access controlled policies (ACLs).

Provide deny access to SoftType in context/container where its not applicable

Or

Provide deny access at level where this Object is defined (Site/Org) and provide Create/modify/etc access in desired context/container.

Regards,

Avinash

-----End Original Message-----

[MikeLockwood]

ACLs work but the user doesn’t see the result until they select Finish on the New Doc wizard.
Using OIR’s with Lifecycle has the advantage of removing the type from the list of types to select.

[Avinash]

Hi Mike,

If ACL's are applied correctly (Create/Modify/etc deny access by Role) then Soft Type or Object will not apear on User's create window.

Regards,

Avinash

In Reply to Mike Lockwood:

ACLs work but the user doesn’t see the result until they select Finish on the New Doc wizard.
Using OIR’s with Lifecycle has the advantage of removing the type from the list of types to select.

[ddemay]

I think also it depends on how you designate a context/container for a
specific type of document. While I haven't had a requirement to honor to
setup such a system, I would use ACL's or non-instantiable flag to control
that.



There are OOTB soft types for documents, etc. that even when set to
non-instantiable in the type and a desire to avoid hard deny rules, the
lifecycle option works fairly nicely. My only dislike of the option (and I
use it for one or two types) is that the MethodServer.log has entries for
the hack, stating invalid lifecycle for type XYZ.



To be completely honest, I'm not sure why the type pickers in the UI's don't
just have that last hail Mary via a properties file setup?? PTC gave
customizers the ability to define the seed type picker setup but didn't
carry it 10 more lines of code forward to also check for a properties file
entry. Ten more lines of code?!? I smell an enhancement request coming.



OrganizationName.ContextName.TypeName.visibility=true/false, default to true
if not set.



This is different from ACL route per se, as it handles the need to avoid
customization of the type picker. I do something similar for my generic
action filter class and it works swell.





- David DeMay

[MikeLockwood]

I'd be very interested in seeing an example with ACL's. After hours of playing with this, I couldn't get it to work except when the user selects Finish in the New Doc wizard.

[ddemay]

Your issue Mike and subsequently mine is we try to get our ACL's at the Org
level. That abstraction does present an additional challenge to the folks
who have the school of thought that each product or library or folder within
can be strewn with additional ACL's.

[Avinash]

Hi Mike,

Please refer below example (tried on 10.1 M040)

• 
  
• Added a below ACL rule at Organization or Product Level
  
  • 
    
  • Context: Org or Product
  • 
    
  • State: All
  • 
    
  • Permssion: deny for Create (for all other None)
  • 
    
• 
  

After adding this ACL user (wcadmin) was not able to see Document Type into Create Doc window

I hope this example will help.

Regards,

Avinash

[HugoHermans]

My approach to accomplish this is to define most ACL's on ORG level (or as high as possible in the hierarchical structured domains), except the 'allow create' rule. This rule is only defined where I want users to have the possibility to create that particular softtype. Quiet straightforward, with one caveat, being the restriction to move objects.

I would be interested to know what the life cycle workaround brings as extra.

Regards, Hugo.

<< ProE WF5 - PDMLink 10.1 M040>>