Community Tip - Did you know you can set a signature that will be added to all your posts? Set it here! X
Windchill 10.0M020: How do we prevent users from creating new objects in the root folder of a product or library? They should be able to create in subfolders. I tried denying permissions for the default domain and granted permissions on a different domain then used it for sub folders, but the sub folders are also getting deny permissions. What is the best way to do this on Windchill 10M020?
Solved! Go to Solution.
Deny permission is the strongest and can not be overwritten with grant on a lower level. Deny should only be used in very rare cases. All ACLs will be inherited from parent domains.
You can easily achieve this by removing modify permission for cabinet. That will do the job - all objects need to be stored into folders.
Default Domain of Context/Cabinet Object/TeamMembers/Read
Message was edited by: OliverDroop
Don't attempt to control this via permissions. Instead, configure the OIR for each object type (e.g. EPMDocument) to a folder below root (e.g. /Default/CADDocuments).
Note: This is also an easy way to prevent creation of an object type in a specific Product or Library - don't create the specified folder. For example, we have a Library used for Patent Documents, and do not allow WTParts to be created there.
Thanks for the post Mike. Seems like there is a problem if the folder that we specified in OIR is not existing.
https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS36541
I also tried to direct into a folder which has restricted permissions, in the OIR, but then the location seems to be changing to the value of the "/Default" location.
You should remove the write permission to cabinet object (like root for that context) in the default domain. Subfolder is a different object.
It might be that you need to add modify permission in the subdomain again - not sure how WC10 handles this meanwhile but first I would try without it.
When I did some testing, I noticed that denying the permission for the domain of a top level folder denies permission for subfolders as well, even if those sub folders have a different domain with grant permissions. I expected it to work but it was not.
It works the other way, the root folder domain has grant permissions and the sub folder has deny. This works.
Deny permission is the strongest and can not be overwritten with grant on a lower level. Deny should only be used in very rare cases. All ACLs will be inherited from parent domains.
You can easily achieve this by removing modify permission for cabinet. That will do the job - all objects need to be stored into folders.
Default Domain of Context/Cabinet Object/TeamMembers/Read
Message was edited by: OliverDroop
Thanks Oliver, I tested what you mentioned -
You can easily achieve this by removing modify permission for cabinet. That will do the job - all objects need to be stored into folders.
Default Domain of Context/Cabinet Object/TeamMembers/Read
and works like a charm !
Hi AJ,
Can you confirm that this is where I would go to make the necessary changes to the permission? I have the same issue as you where I would like to prevent the user from creating new objects in the root folder but still allow them to create new objects in the sub-folder. I am on WC 9.1 M050, not sure if your solution will work for me but I am willing to give it a try.
H,
I looked at your image and that is the correct place where you need to make the changes. I have only tried this on 10.0M030 though.
-AJ
@OliverDroop, I was able to make this change and it definitely prevents new items in the root folder (parts, docs, cad), but it also prevents me from creating change objects. What is the trick to allow change objects to be created? Do I need to modify the OIR for change objects? Are there other objects other than changes dependent on the root folder?
UPDATE: found https://www.ptc.com/en/support/article?n=CS258736 and will have to check when our next 11.0 rehearsal is ready. Good to see these will be foldered objects like everything else.
You can define a dedicated location for Change Objects already in 10.2.
Change Tasks will always reside in the context of ECN and are not folderable. Internally they are in the cabinet