Centralizing policies to one domain & shared teams

[gchampoux]

I am in the process of learning & testing Intralink 9.1, and am wondering how to best define domain policies.

I am thinking of using Shared Teams to control access for everything, as PTC seems to encourage this.
All of our shared teams will have the same roles, but with different principals assigned to the roles of each team.
I could define the policies (by role) at the team level, but I expect they would all be identical, and therefore redundant.
I figured that I should set policies at the highest domain possible and let everything trickle down (inheritance).
In theory, I would set the policies in the / (root) domain for the site, but PTC recommends against messing with root.
However, we only have one organization, which is all that is allowed in Intralink anyway.
I figured I would define all policies in the /Default domain for the organization.
Then I would make each descendant domain as empty as possible so that everything is inherited.
This would apply to the descendant shared team domains and their descendant products/library domains.

With all that said, I am somewhat concerned about one aspect of shared teams.
Once a product/library is defined with a shared team, you cannot change it to a different team.

Does this make sense?
Or might I be setting myself up for problems?

Gerry Champoux
Williams International

[MikeLockwood]

Important and complex subject...


1. The help for Shared Teams says something to the effect that you have to have Shared Teams in place before creating a Product or Library that will use them. Which a) eliminates their use for anyone already using the system in production b) seems like it forces you to have all Shared Teams thought thru for all time before creating any Product or Library. Because of this, we have (so far at least) ignore Shared Teams.



2. OTB, very few ACL's are at Site or Org level. The vast majority are created at Product / Library level because they are included in the Product and Library templates. It creates an absolute maintenance / troubleshooting nightmare to have them spread out this way, and we fully agree that it's best to put all that are common one level up (at Org level). Essential to make this work is to create your own Product and Library templates with minimal ACL's in them so that all future contexts inherit from Org level.



3. Be careful about applying the same permissions everywhere. At a minimum, you probably need at least one restricted-access Library for things like Drawing Formats. Also, purchased standard parts (screws, nuts, etc.) which are used pretty much everywhere need a different process from custom items and generally need different access controls.



4. One major irritation is that at Site or Org level, you cannot see what ACL's are in each Product / Library - you have to go to each in order to examine. OTB but hidden pretty deep is a report that lists all ACL's, but it's highly unreadable. We created a query builder report that dumps to Excel for this purpose - far more usable.


5. Careful about putting things at the Org /Default domain also. If you ever install ProjectLink in the future, they will also then affect Projects. Best to go one level down to Org/PDM/Default.



6. Also, plan Teams carefully (fortunately all but Shared Teams are very editable). Much more flexible to use Team Templates in general than Context Teams.


Big, complex and difficult subject. All of this we learned gradually the hard way - could really use better and more realistic examples in this area from PTC in the business admin guide and PTC U, etc.

[ddemay]

Shared teams can be used, but where PTC has not finished the job is a batch substitute/replace method.

Also as more things have become soft typable, you can write ACL's that prevent undesired level of access based on soft type. Folder/SubFolder is a good example of this. I can have multiple roles on one team who have different access to create different soft typed object within one container/context.

This actually could lead to the need to have separate domains and more centralized ACL control.

Too many site try to create too few roles. Best to really look at requirements and see how granular you can get.






Sent from my Verizon Wireless BlackBerry

[HugoHermans]

Hi Mike and Gerry,

Have a look to http://communities.ptc.com/docs/DOC-1515. I tried to summarize my approach on configuration of access rights. Feel free to add comments, remarks, ...

Regards, Hugo.

<< ProE WF3 M230 - PDMLink 9.1 M050>>