Another ACL question - concerning domains

[davehaigh]

After doing some investigation into how our system was set up, I've figured out why I have extra domains, but not sure if there is a better way to do this or not.

Product Folders
=============
Our Product template makes products with the following sub folders. (Approprate OIR are setup for various object types)
Analysis Documents
CAD Documents
Check In Forms
Coordinator Documents
Engineering Documents
Manufacturing and Inspection Documents
Promotion Request

When our system was set up in PDMLink 8.0, additional domains exist under the Product domain for:
Analysis
CAD
Coordinator
Engineering
Manufacturing and Inspection

These domains give unique access permissions for these various roles in the team for each product.

This makes some sense. You want Coordinators to be able to put purchasing documents in the Coordinator Documents folder, but you would want to give them modify access to your ProE files in the CAD folder, and you wouldn't want a CAD designer mucking with the purchasing docs.

The problem with this approach is that if you want to change access for a role in all contexts, you have to go into every product and all affected domains and change the role. Essentially a mind numbing task, with a huge potential for error.

This was put in place in rev 8, are there better methods in 9.1 or 10 that scale better and essential accomplish the same thing?

The other thing about this setup that causes me questions is all these permissions are set on WTObjects. Should the ProE objects be limited to EPMDocs.

David Haigh
Phone: 925-424-3931
Fax: 925-423-7496
Lawrence Livermore National Lab
7000 East Ave, L-362
Livermore, CA 94550

[AL_ANDERSON]

You could make each of the following document types a soft type in the
Type and Attribute manager, then set up organization wide roles, rules,
and OIRs for those light types accross all contexts.

Analysis
CAD
Coordinator
Engineering
Manufacturing and Inspection

That would allow for common rules with common roles to apply on a type by
type basis accross all contexts. You also get the benefit of defining a
different icon for each type, and different attributes (if you have any)
for each type.

Al Anderson





"Haigh, David A." <->
10/24/2011 05:04 PM
Please respond to
"Haigh, David A." <->


To
"-" <->
cc

Subject
[solutions] - Another ACL question - concerning domains

[AL_ANDERSON]

In my last post, I was assuming that your "CAD" folder was for
WTDocuments. If your "CAD" objects are EPMDocuments, then you can simply
set up rules for EPMDocuments at the org level if you want those rules to
apply equally in all subordinate contexts. Typing, in that case, would
not be necessary for your "CAD" objects.

All the other folders, however, look like WTDocuments that could have
their documents light-typed under "Document" or under "Reference Document"
to allow for type-specific rules set at the org level and applied across
all subordinate contexts on a type by type basis.

Al






"Al X. Anderson" <->
10/25/2011 11:03 AM
Please respond to
"Al X. Anderson" <->


To
"Haigh, David A." <->
cc
"-" <->
Subject
[solutions] - RE: Another ACL question - concerning domains

[RajuPulavarthi]

Hi all,
We are exploring an option to link WTUser Objects as IBAs to the Change Objects. The OOTB UI to create a Reference Definition limits the classes that can be selected to 'WTOrganization' and 'ClassificationNode'. Have anyone used this IBA type to link to attributes of any other type? If so, How were you able to do it?

[cid:image001.png@01CC931A.5A4A8E10]

I have also noticed that one of the attribute definitions in OOTB Attribute Organizer PTC_SYSTEM_ATTRIBUTES is referencing a class other than the two mentioned in the above screen shot. There must be a way to create the definition using the load files.

[cid:image004.jpg@01CC931B.269809C0]

Thanks,
Raju


Raju Pulavarthi
-
sjm.com