Introduction

A document ment to contain best practices on the configuration of access policies.  Since this is subject to personal appreciation, professional contexts, etc, it is highly likely that this document will contain contradicting opinions.  At least, when other authors add their concepts as well.

Concepts A

These concepts are based on my experience in Windchill 9.1 (Michel Van de Wiele), and input gathered from the PTC/User mailing list.

An important requirement is that the day-by-day users have to understand why they can or can't do or see things, and maybe even more important, that the management has an understanding of it.  So, the general concept should be straight forward and generic among containers.

The general idea is that objects are always to be considered as confidential, and that actions have to be allowed explicitly.

Domain selection

• Try to configure as much as possible in the PDM domain.  This will not jeopardize your projects in ProjectLink, and is general enough to avoid repeating the rules in every product or library.
• Avoid the default domain in the individual products and libraries.  During the migration from 8 to 9.1, a lot of rules were added to this domain, so it is likely that this will happen again in the future.
• Specific rules are only added to subdomains of the product/library default domain (i.e. the second level).

Folders in products/libraries

• Avoid to add anything to the root folder of your container.
• Create subfolders according the object types (wtparts, wtdocuments, epmdocuments, ...).
• Within these first level subfolders, objects are to be considered as confidential.  Further subfolders may broaden the accessibility.

Softtyping

• Create a first level softtype, based on the department (Aftersales, R&D, Purchasing, ...).
• Second level softtypes represent the general usage of the document (general, manual, instruction, meetingnote, ...).

Context Roles

• Try to interprete and configure each role in each product/library always in the same way.  The Engineering/Designer is always the main author in the container, Guest only has read access to Released objects in the Public subfolder (as an example).

Access rules

• Most of the rules are configured (once) on PDM-level, but this domain never ever should contain create-rules.  To reduce the number of rules, most of them in the PDM-domain are based on root type or first level softtypes, seldom on second level subtypes.  Since the interpretation of the context roles is generic amoung all containers, it is obvious to define these common rules for these roles.
• As said, I never add rules to the default domain of a container.
• In the first level of subdomains, you will find all necessary create-rules, based on second level objecttypes.
• In the second level subdomains, I broaden the access rights.

General implementation (as an example)

• Designer/Engineering has general read/write access to most objects in the container.
• Industrialisation has general read-access, but no write access
• Member has only read-access to Released objects, and read access to all objects in the Public folder
• Guest has only read-access to Released objects in the Public subfolder.

Final Remarks

• Shared teams seems to lack flexibilty.  They have to be present at the moment of container creation, and are hard to change afterwards.  Unless someone can shed some light on this, the concepts above disregard shared teams.
• To ackomplish restricted access, assigning groups to container roles should be sufficient.  E.g. the library containing drawing formats, designers are assigned to the Members role.

Concepts B

... (to be completed)

Concepts C

... (to be completed)