What is the necessary info you must have before creating an additional Organization?

[Pieter_Du_Toit]

Hi,

I am completely new to this and not really sure where to start. I am also not really able to find a How To guide apart from the odd 6 min video.

The setup will be as follow: Company A bought company B and company B will now become the new additional organization. Company A must be able to see company B's data but not the other way around.

I am not sure yet whether there will be made use of only one server since the companies are located in different regions of the country.

What is all the info/requirements that I need to know before creating an additional organization.

Appreciate the help.

Regards

[STEVEG]

Why do you want to create a separate Organization for them?

We purchased a company a few years ago.  All we did was get them in to our existing setup.  We didn't create a separate organization for them.

You could also create a separate Context in your current organization.

[yadavankur]

I agree different Contexts might be a better idea, though it might require re-looking at policy permissions especially if they are set up at org level, but long term it is easier, especially at the point when business decides they want to start collaborating. Just setup the product with specific permissions, and OIR, and then save one as a template for reuse.

[Pieter_Du_Toit]

Thanks, also think contexts will be the better option.

However, if the the organizations use different ways of working (life cycle, work flows, etc.), is it still possible to manage on context level or should one then rather think of creating an org?

Appreciate you help.

[STEVEG]

The workflows can be used/applied regardless of context.  I think you can do the same with lifecycles.

However, I do not know if there IS something that would suggest using another organization would be a better option.

Anyone else know?

[yadavankur]

You will load the lifecycle, workflow, team template for both at org level and the OIR at context level will take care of assigning the correct rule. The numbering scheme might be different too but consider combining them if possible, otherwise those are also in OIR and database. The versioning scheme is also in OIR and specified in wt.properties. You will have to do these activities if you are going for same or seperate orgs. If something has same name just suffix it for eg. approver, acme_approver. As long as you don't have any customisation I don't think there is anything to worry about, other than migration.

[Pieter_Du_Toit]

It seems that I am trying to over complicate this...

I am definitely just going to create new contexts.

But the requirements for the two companies has changed a bit now. Company A's users are not allowed to see the old as well as new data that is created by the newly acquired company B's users.

Do I now put company B's users perhaps in a new group and take away even basic read rights on company A contexts and vice versa?

[yadavankur]

What I would check are domain policies at levels above the context levels because they are all additive, and not play around with the permissions on domain named system, finally try to avoid setting deny permissions. The groups are not absolutely necessary, depends on your setup, but if you are setting permissions using groups then yes you will need it. It is generally a better idea to set permissions on roles.

[Pieter_Du_Toit]

Not sure if I understand correctly but here goes...

If any new user is created he gets added to the Team Members and Guest group. Currently the product template is set up so that the group Team Members and Guest have Read and Download rights.

https://support.ptc.com/help/windchill/wc111_hc/whc_en/index.html#page/Windchill_Help_Center/SecurityMgmtAccessMultiTableRef_Change_permissions.html

"

The following additional system groups are created for use with context teams:

• A Team Members group contains all team members in the application context. This group is created in each application context. Windchill maintains this group; you cannot manually change the membership of this group.

In some places, this group is shown as Team Members and, in other places, it is shown as teamMembers.

• A set of system groups representing the organizations of the members in the context team. Each group contains all of the people from one organization who are members of specific application context. As team members are added and removed, the organization groups for the team are automatically updated. When a user from a new organization is added to a context, the system automatically creates the system group to hold the members of the organization. The name of each system group is the name of the organization. Windchill maintains this set of groups; you cannot manually change the membership of the set of groups. "

The issue that I no have is that when I add a new user from Company B he already gets Read and Download rights to products that were/are created with Company A's template.

Is there a way that I can prevent company B's users from being placed in the Team Members and Guest group.

From the url above it seems it is not possible?

Appreciate your help!

[yadavankur]

Use Access Information wizard to view where a user is getting permissions from.

There are quite a few reasons someone could be getting read.

1) You have 'read' granted to teamMembers (this is out of the box) and one of the roles in the context team has a group that is made up of all the users (or subgroups that effectively add up to all the users)

2) You have 'read' granted to the thisOrg pseudo role or some other group where the users are added and the permission is defined on group instead of to role

3) You have 'read' granted through lifecycle template (in Access Information the source will show up not as "Policy" permission but as "Life Cycle")

Also, it could be permission on WTObject (instead of WTPart for example). If you can't figure it out just give tech support a call, they will be able to recognise the source of the permission.

[Pieter_Du_Toit]

This is so helpful, thank you very much!

I have inherited the config from a previous admin so it is always a hassle to get a grip on their way of thinking and doing things.

For testing I just decided let me first go with creating a new Org and the I can limit access on WTObject for the one org and vice versa.

Will see what the customer says.