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

Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X

Dual contractors in same Product, need help?

JohnWenner
6-Contributor

Dual contractors in same Product, need help?

Our scenario is we have two contractors delivering a vehicle in the same Product.  We will refer to them as CONT1 and CONT2.  CONT1 is building existing vehicles and CONT2 is building new Model Year.  Probably 90% of the data is common between the vehicles.

 

The goal is CONT2 can see EVERYTHING (no real issues); however, CONT1 cannot see anything NEW CONT2 creates.  For example, we have a WINDOW at REV.C and CONT2 revises to REV.D.  Now, CONT1 can see REV.C, but not REV.D.  

 

Any ideas how to execute this?  Should I use Security Labels or possibly something like Edit Access Control and use folder control within the Product?   (Not sure our Admins have that setup yet for us).  

 

I was thinking I could move REV.D to the CONT2 folder or possibly set a Security label for that REV.D file.

 

Thanks!

1 ACCEPTED SOLUTION

Accepted Solutions

@JohnWenner , do you have ProjectLink module installed? This indeed does work. You are able to share specific revision. If the person has access to the Project, they will only see that version and this leaves the latest version in the Product area.

avillanueva_0-1681910770695.png

avillanueva_1-1681910848667.png

 

View solution in original post

12 REPLIES 12
BenLoosli
23-Emerald II
(To:JohnWenner)

Security labels are over kill for this type of data segregation.

Set permissions so that Cont1 cannot see items that are not released. Only release items that are in the existing model.

Another method would be to use multiple contexts, one for the existing, one for the new. The new context gets the new revisions that Cont2 is doing only. Context ACLs can prevent Cont1 from seeing the work that Cont2 is doing in the 'NewModel' context. When it is done, move the files into the existing model context.

JohnWenner
6-Contributor
(To:BenLoosli)

Can you move files between context at a certain revision.  So context 1 would have REV.A thru C and context 2 has REV.D and above?

 

BenLoosli
23-Emerald II
(To:JohnWenner)

You cannot put different versions in different contexts or even folders. They are tied by the master name index so you move all or none.

avillanueva
22-Sapphire I
(To:BenLoosli)

I believe projects allows sending a version to the project. Sharing?
JohnWenner
6-Contributor
(To:BenLoosli)

I was able to move files in the same Product.  For example, REV.- was in one folder and REV.A was in another folder.  So that is possible, I just don't think you can do that across contexts.

 

Hi @JohnWenner 

Unfortunately you can just move different versions between several folders but only in one context .

 

So If you would like to achieve your needs you would need to create folder domains to set ACL rules for specific folders to allow or disallow the access to the objects.

 

a move action allows chose different folder  with following setting in the wizard

HelesicPetr_0-1681909718540.png

PetrH

@JohnWenner , do you have ProjectLink module installed? This indeed does work. You are able to share specific revision. If the person has access to the Project, they will only see that version and this leaves the latest version in the Product area.

avillanueva_0-1681910770695.png

avillanueva_1-1681910848667.png

 

We do have ProjectLink installed, but I don't think it will work since we have probably 100,000 files that we would be required to share.  I think the level of management for that would not be ideal.  I was hoping to control with access control possibly. They still may need to do Change Notices (both CONT1 and CONT2) based on supply management and other changes.

 

with too many files to manage in PJL, it sounds like @HelesicPetr suggestion is a good one. we are using multiple external partners in our design process and spend a lot of time identifying commonly used items and moving them to a new container where we can provide Read Only access to the external participants. this helps ensure they are not attempting to change items used in many products and only have access to change items in the product they are working on.

jbailey
17-Peridot
(To:BenLoosli)

I don't necessarily know that security labels are overkill, this is what they are designed for.  However there are also license implications.  Security Label management is available on Windchill Advanced / Premium.  Windchill Base licenses require secure collaboration license in addition (at a 1:1 ratio for all of your base licenses, regardless of who is using the SL functionality).  I highly recommend against using edit access control.

Sounds like a case for a project. Put CONT1 in a project and share what you need with them. They operate in the Sandbox and everything can be checked into the Product when complete. 

Agreed. It is the prime use case for PJL

Top Tags