Intralink 9.1 Library - Establishing Access Controls

[ScottPearson]

Hello fellow 'chillers,

I have created a Library in Intralink 9.1. In that Library, I have created several Folders as a way to organize standard parts by categories (i.e Nuts, Bolts, Washers,Gears, etc.). Within each of those Folders, I have a Subfolder called "Upload".

Here is what I am trying to achieve....

I, of course,want the typical User to be able to access the standard parts in the Library's main Folders (e.g. to insert into assemblies) but I do not want the Users to edit the geometry of those standard parts. No problem thus far since the default access control settings in the Library result in that behavior (i.e. my Library was created from the "Library Template" named "General Library.")

That said, I do want my Users to be able to save content to the By having that permission, my Users can create (or download from the internet) standard part geometry, save that part into the Subfolder, yet the part will not go into the official top Folder until moved there by a Library Manager (or similar WC higher life form such as wcadmin).

My problem is: How do I grant permission to the Subfolders yet preserve the restrictive permission of the top Folders?

My failedattempt to achieve this was to create a newRole(called "Uploader") per this tidbit contained in the WC Business Admin Guide:

[MikeLockwood]

Use state instead of Folder location to control permissions.

1. All can create in this Library - object uses first state of the assigned lifecycle.
2. (Probably) All can then Modify / Modify Content in this Library while still at the first state. Also allow Modify Identity (Rename / Renumber) while at the first state.
3. Control getting to the next state via Set State or Promotion (lots of options here).
4. Control who can Revise in this Library.

No need to use folders at all - which eliminates moving. Setting up the states and the processes for moving between states and to the next Revision is the key business process planning needed.

In my humble opinion, all the published info about this is very very non-helpful.

[HugoHermans]

Hi Scott,

Access Rights to (sub)folders are configured by the domains assigned to these (sub)folders. And the hierarchical structure of your domains hasn't to be the same as your folderstructure. So, even if '\Upload' is a subfolder of '\root', the domain for '\Upload' may be on the same level as the domain for '\root', and this way, may have completely different access rules.

But '\Upload' seems to me a temporary folder. A procedure were you have to move objects from folder to folder, doesn't seem a nice practice to me.

Met vriendelijke groeten, Best Regards,

Hugo.

[bfrandsen]

An easy OOTB solution that we use is to have the designers add the CAD models to a Product Folder and ask the Library Manager to move it from there to the Library. Our Library Manager is also Org. Administrator so all access rules are in place.

Bjarne Frandsen

(Pro/ENGINEER Wildfire 4.0 M170andWindchill 9.1M060 on Windows)

[sscole1]

Scott, Mike is correct. You should be using state-based access control versus moving objects from folder to folder (and more importantly, you do NOT want to be moving library objects from Product folders to Library folders, since commodity/library objects shouldgenerally will have a differentassociated lifecycle versus product/design objects). The system is designed around Product Lifecycle Management versus simple vaulting. You should set up the library with a library manager(admin), who would be the approver for a promotion from an "in work" lifecycle phase (where creator submits an object and still has read/update control) to "under review" (locked and visible only to librarian) to "released" (locked but viewable/usable by all) to (potentially) "obsolete" (retired so no longer viewable/usable by all (although may still be accessible for existing designsand could/should be replaced through effectivity constraints, etc.),and accessible by librarian for historical/archival purposes).

Steve

[davehaigh]

Whoa there, I don't agree. When PTC set up our system several years ago, they convinced us that we wanted different lifecycles for library parts than we have for parts in Products. This has caused us nothing but grief.

Designers are not typically going to be working in the context of the library. So when they need a library part, they either download it from a vendor site, or make a model from scratch. That model gets created in the context of the product they are working in so it gets those OIR's, and thus the product lifecycle. Now if you want to move the file to the library you can't because the library has a different lifecycle.

Our situation is made even worse because we have multiple orgs, and our library has its own org.

David Haigh

[sscole1]

David, I understand the concern overthe contexts in which users might originate data. That issue should be mitigated through process - users DO have the option to specify where CAD (and other) data is to be checked in. If they are knowingly creating/uploading library components, then they should be submitting them to the appropriate library and observing appropriate library standards as well (start part, standards of designand parameter requirements, for instance). In the instance that objects are not created in the correct context, they CAN be moved (as of R9) and, with appropriate access permissions, the lifecycle can also be reassigned to match the target context. To mitigate the potential headaches, you can actually use the same lifecycle across contexts and make provisions for library-specific promotion policies - for example, in a product context, you may require additional lifecycle steps (prototype, SIT,etc.) that are not required of library components; in that sense, you can provide the library manager the ability to bypass those states to simplify the promotion process. In either case, from a holistic data management POV, library components are typically used across products and even lines of business, so it is important to take this into account when designing the PLM system. If you house library components in product contexts, you are going to need to provide ubiquitous access to those products for everyone in an organization.

[DonSenchuk]

I'm with you on this one David. While users can always be instructed to put new CAD files in the appropriate place (Library), in my experience it simply doesn't happen that way. Some users are really good at remembering, some so-so, others just never pay attention.

A couple years ago I was part of a team migrating from Intralink 3.4 to Windchill 9.1. The 3rd party tech we brought it basically insisted we apply the same life-cycle to our products and libraries. His explanation matched what you mention; he had seen enough implementations that did not use the same life-cycle cause problems that it simply wasn't worth the headache. (As it happened, after implementation there were tons of files getting checked into products then moved to libraries. It's just the nature of end users.)

I'm certain it's possible to move objects from a product toa library, assign it to the new life-cycle template, etc., but the amout of work is certainly far more than simply moving any objcts that get checked into the product as opposed to the library.

As with so many other things, keeping it simple works out the best.

In Reply to David Haigh:

Whoa there, I don't agree. When PTC set up our system several years ago, they convinced us that we wanted different lifecycles for library parts than we have for parts in Products. This has caused us nothing but grief.

Designers are not typically going to be working in the context of the library. So when they need a library part, they either download it from a vendor site, or make a model from scratch. That model gets created in the context of the product they are working in so it gets those OIR's, and thus the product lifecycle. Now if you want to move the file to the library you can't because the library has a different lifecycle.

Our situation is made even worse because we have multiple orgs, and our library has its own org.

David Haigh