cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Controlling access for Product root level

RonGrabau
7-Bedrock

Controlling access for Product root level

I want to be sure that my users cannot write files to the root folder of a Product. I have read what I can find on the subject but I have yet found the instructions that work for me. I opened a couple of calls to PTC but I have not received an answer to this question. It seems like I am just missing something simple.

Ronald B. Grabau
ME Applications Engineer
HP - Houston

6 REPLIES 6
avillanueva
22-Sapphire I
(To:RonGrabau)

Ugly solution but someone might have something better. Create a domain
under default that has all the normal rights that the default domain
does now. Enabled folder level access control. Assign all folders and
subfolders to the new subdomain. Turn off create and modify rights to
the default domain.



What's the reason for needing this?


I believe the way to handle this is by adding another domain. When you
create your subfolders, they would belong to this domain, and you
would write the majority of your ACL's to this domain. leaving the
Root Folder as it is and have a more strict set of ACL's around it.

This should allow you to achieve what you are looking for.

Steve D.

Quoting Ronald Grabau <->:

> I want to be sure that my users cannot write files to the root
> folder of a Product. I have read what I can find on the subject but
> I have yet found the instructions that work for me. I opened a
> couple of calls to PTC but I have not received an answer to this
> question. It seems like I am just missing something simple.
>
> Ronald B. Grabau
> ME Applications Engineer
> HP - Houston
>
>
>

I agree with both Antonio and Steve that the domain would be best - but highly question the need.

We have all objects at root level except folders used for change objects.

Hi Ronald,

Extra domains for the folders is one thing, but don't forget to tweak
your OIR in order to point the particular (soft)type to the particular
subfolder. In this repsect, as far as I know, not all (soft)types can
be subfoldered. Change object for instance.

Two examples where subfoldering can be interesting :
1/
I have WTDocuments in two different sub-rootfolders, because they differ
in nature and according in ACL's.
2/
Although WTDocuments are not allowed to be written in the root, I give
'create' - and only 'create' - access to softtypes in the root. In the
subdomains, I give read, modify and revise rights on WTDocument-level.
This way, I only have one rule to add when I define an extra softtype.
Maintenance effort can be reduced, since the number of lines pro domain
is reduced. This can be done since you need create AND read access in
order to create an object.

One last thing :
Access rights from the life cycle seem to overwrite these from the
domains.

Regards, Hugo.

The difficulty of doing folder level access controls in Windchill really
frosts my strawberries! Intralink V3.4 is all about using folders. We
have top level project folders, and "eng" and "mfg" subfolders.
Engineering gets read access to the tooling designs, manufacturing gets
read access to the product designs. It works great and has saved our
bacon on many occasions. I understand the folder-level domain thing in
Windchill. It just looks pretty ugly ... it has us considering splitting
our projects up into eng and mfg product folders ... grumble, grumble.
Did I mention we'd be shuffling 1.3M files around? I'll be selling
flaming torches and picket signs outside the PTC User hotel here in
Orlando ... cash only.



Robert R. Green

Lockheed Martin Missiles & Fire Control

Orlando, FL



From: Lockwood,Mike,IRVINE,R&D [

Which release? I don't think you need the extra domain in 9.0 if you have enabled ad-hoc access for pdmlink.

Tim Atwood

PTC Enterprise Deployment Center

Top Tags