Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X
Our system is currently only utilizing one Organization. It is becoming more evident that we need to split our implementation into at least two Organization contexts. What I'm wondering is:
Al, from my understanding those are some limitations from older versions of Windchill, pre 8 or maybe even 7.
On my dev 9.1 instance, I was able to create a new organization, add a new product into it. When you create the organization there is a checkbox that allows you to either see users from all orgs, or just that organization, so I was able to add team members from another organization to it. I was also able to cut a file from a product in org 1 and paste it into a product in org 2.
From my experimentation, you can Move, Cut and Paste between products/libraries/projects that reside in different Organizations. Packages are for a completely different purpose.
Our goal would be to take our mono-organization configuration and split it to a multi-organization system. Once that split is done, there is no need to share data between the organizations. Users, maybe, but not data, they each have their own libraries and don’t share any common cad parts.
From what I’ve seen testing this out today are issues/p.i.t.a.
· Can’t move a Checked Out item
· To create a product/library/project in an organization your user account must belong to that organization, so this would add a necessity for extra admin accounts for just myself to create the products in the other org… Not convinced of this, but this was my initial testing conclusion.
· Can’t move the initially created End Item of a Product to a new Product, no big deal if it’s not used, but some of our products use this end item in the product structure as the top level item. (not sure how many, but have seen it done at least once)
Steve D.
You can move this End Item, you just need to create another End Item, set it as the Primary End Item for that Product. (Only applies to Products created prior to 9.0)
In Reply to Stephen Drzewiczewski:
· Can’t move the initially created End Item of a Product to a new Product, no big deal if it’s not used, but some of our products use this end item in the product structure as the top level item. (not sure how many, but have seen it done at least once)
My interpretation of the intended use of organizations is to allow entirely separate entities to share the same Windchill installationhardware, Organizations allow you to do that without fear of anyone accessing anything they shouldn’t and makes management of the segregation easy from an administrative perspective. From that view point Organizations in PDMLink are far from worthless, and meet their intended use case.
I think the only issue is if you have users who need to be members of more than one organization, it seems they might need a user account for each. Admin user’s aside, if that is a common requirement, probably you shouldn’t be using organizations to divide your data and should invest more time in access control rules and better utilizing Products and Libraries instead.
-----
Lewis
I too have porblem with 2 organization. If user have access to each of 2 organisatin and in each of them exist library with name "TEST".
When user clik on link library list he see to name and he can't understand which library corresponds to a organization. How I can can select with diferent color library label with same name?
Ivan Feofilov owner 4customizer.com
What issues did you guys have with working with multiple organization containers?
I see someone stated rules. How were these rules applied to have issues?
In response to my own question, the reason why I'm asking because there are cases where you apply OIRs and ACLs at all levels from SITE, Organization, Program, Project, Product, Library and Domain (folder) level for fine tuning, standardizing and globalizing your controls.There are cases where OEMsand partners may have their own information that specifically belong to them and your internal assemblies call out the the top assemblies. If you efficiently use Supplier Management, they can check into their ownorganization context and ORGID tied/associatedto thier own MFG or supplier part. Or you can call itin your internal ProE BOM without any conflicts of number and organization. Hence, full collaboration. Sometimes using the ProjectLink workspaces are confusing because ProE users just like to check in their top assemblies.
I haven't had issues with multiple orgs.