Validator to create type of an object only in certain containers

[aachanta]

Hi All,

Can we get an API or piece of code where we can create certain documents or parts or any other object type only in certain products or libraries through a validator. 

[BjoernRueegg]

I would recommend to create a policy with denied creation right. So the user won't be able to create any of this type. The only disadvantage is, that you need to copy this policy to all the different context.

[aachanta]

Hi @BjoernRueegg 

There are more than 200 containers and creating an ACL is extremely time consuming and if we create any products or libraries again we need to get ACL manually created again. 

So can we have any other way like a validator to make sure that a document type is created only in certain products or libraries and not in all. 

[ScottMorris]

How many containers are excluded and how many are allowed?

[aachanta]

hi @ScottMorris 

there are more than 2000 products and 1000 libraries where we want this to happen only in some certain libraries like 200 and 300 products and not for all.

[BjoernRueegg]

@aachanta I would create a acl loadfile to load the policies to the different containers. I you are using a listener, user can still select the document type, fill and upload the document and at the end when they click to create it, an error appears, that they are not allowed to create the document. This is not user friendly.

CS24534 

[rhart]

Hi @BjoernRueegg 

An another option is with an OIR.

For example, to deny creation of all documents an sub-types:

<AttributeValues objType="wt.doc.WTDocument">

   <AttrValue id="lifeCycle.id" algorithm="com.ptc.core.foundation.lifecycle.server.impl.LifeCycleTemplateAttributeAlgorithm">
      <Arg>Invalid Type in this Container</Arg>
   </AttrValue>
</AttributeValues>

[d_graham]

With that many containers I’d go the validation route too.

How about a listener that prevents the creation of specific types in the containers. If user attempts to create type in non-approved container they are immediately alerted.

This can be easily scalable too by any  admin (no programming required).

Do you have a list of the types and the containers handy? The list should be stored in Windchill. Admin can edit the list on an as needed basis. Super easy to update the list.

You might also want something to prevent moves to inappropriate containers.

[aachanta]

Hi @d_graham 

Can you let me know how do i set up that listener without any logic being built so that I can try the same

no we don't have it handy

there are more than 2000 products and 1000 libraries where we want this to happen only in some certain libraries like 200 and 300 products and not for all.

[jlecoz]

Just a reminder that may not apply easily to your case. It is possible to set access rights on roles at the organization level using dynamic roles.  Doing so reduces greatly the number of ACLs to manage when having a large number of products or libraries. You can still refine the access control at lower level if needed. I used that in the context of a multi-organization implementation.

[BjoernRueegg]

This is also a valid solution. Creating a new role and the policy entries on the org-level.

Unfortunately also there a loadfile needs to be created to load first all roles and afterwords add the user/group to the context where the document types can be created.

[d_graham]

To be clear re: the OIR invalid Lifecycle solution.

1. This technique will work if ANY of the OIR attributes' values returned from their algorithm is an invalid value.

2. It affects all types under the type the OIR is applied to.

For example, if you have type WTDocument | subtype1 | subtype2 and you want the users to be able to create subtype2 but not subtype1 the OIR solution will not work.