Best Practice Document for Project Level Security

This document lists out the best practices for project level security. This is derived from frequently asked
questions by the customers.

Project Application
1. A user cannot have different privilege status in same project.
Example: If a user has both Project Author and Project Team Administrator privileges, then Project
Team Administrator privilege is considered.
2. What is the maximum number of projects you can use in Teamcenter?
The maximum number of projects depends on the number of team members in each project. If the
average team size is 10 to 20, then you can go up to 10,000 projects. If average team size is 100 or
above, then you can go up to 5,000 projects.
3. How to use ITKs to change Project Team?

PROJ_assign_team_members

Dos

Make sure you call PROJ_ask_team first, then use the output of this ITK to form the input of
PROJ_assign_team_members. If you are adding new privileged user or new project team
administrator, check if they are already in the project members first.

Don’ts

You should not provide a user object as one of the project members. The project member should
only be either Group type or Groupmember type.

Assign/Remove security attributes

Project assign/remove to Folder and its contents
Do not add propagation rule to assign and propagate Projects to Folder and its contents.
Best practice is to assign project to Folder and its contents, use “Tools->Project->Assign” menu or “RMB-
>Project->Assign” menu.
Project will be explicitly assigned to the Folder and its contents.
To remove project from Folder and its contents use “Tools->Project->Remove” menu or “RMB->Project-
>Remove” menu
Project will be removed explicitly from the Folder and its contents.

License attach/detach to Folder and its contents

Do not add propagation rule to attach and propagate License to Folder and its contents.
Best practice is to attach license to Folder and its contents, use “Tools->License->Attach” menu.
License will be explicitly attached to the Folder and its contents.
To detach license from Folder and its contents, use “Tools->License->Detach” menu.
License will be detached explicitly from the Folder and its contents.

Unrestricted
Please note that the projects/licenses will not propagate to new objects pasted under the Folder.
The projects/licenses will not be removed from the objects if the objects are removed from the Folder.

Project Assign/Remove to structures

To assign project to structures, select top level BOMLine and use “Tools->Project->Assign” or “RMB-
>Project->Assign” menu in Structure Manager Application.
To remove the project from structures, select top level BOMLine and use “Tools->Project->Remove” or
“RMB->Project->Remove” menu.
Use update_project_bom utility to assign or remove the project to/from the new BOMLines added or
BOMLines removed.

License Attach/Detach to structures

To attach license to structures, select top level BOMLine and use “Tools->License->Attach” or “RMB-
>License->Attach” menu in Structure Manager Application.
To detach license from structures, select top level BOMLine and use “Tools->License->Detach” or “RMB-
>License->Detach” menu in Structure Manager Application.

There is no automatic mechanism to attach license to newly added BOMLine or detach license from
BOMLine which is removed.

It is not recommended to use ps_children propagation rules (Forward->ItemRevision->ps_children->MatchAll-

>SecurityGroupI->All->isTrue->isTrue) to propagate the project or license as it does not consider structure
configurations for propagation and may cause performance issues. This is due to deep cascading of
parent-child relationships leading to large numbers of propagated object lists in POR which will create
performance issues on propagation update.

To propagate propagation-enabled properties from Item to BOMView and from Item Revision to
BOMViewRevision, add the following propagation rules.

Eight rules are required. For all the rules,

Direction = Forward.
Operation = All
Action Condition and Traversal Condition = isTrue.
Secured = yes
Background = no
Source
Business Destination Propagation Propagation
Object Reference Business Object Group Style

Item bom_view_tags Match All Security Group I Merge

Item bom_view_tags Match All Security Group II Fill

Item bom_view_tags Match All Security Group III Order

Item bom_view_tags Match All No Group Fill

ItemRevision structure_revisions PSBOMViewRevision Security Group I Merge

Unrestricted
 Source
Business Destination Propagation Propagation
Object Reference Business Object Group Style

ItemRevision structure_revisions PSBOMViewRevision Security Group II Fill

ItemRevision structure_revisions PSBOMViewRevision Security Group III Order

ItemRevision structure_revisions PSBOMViewRevision No Group Fill

Multi-site
Below is the list of multi-site preferences related to propagation

 TC_multi_site_project_member_bypass
 TC_allow_remove_owning_project
 TC_sync_projects_with_owning_site
 TC_multi_site_gov_classification_user_bypass
 TC_multi_site_ip_classification_user_bypass
 TC_multi_site_ada_license_user_bypass
 ADA_override_on_import

If you are using multisite propagation, please ensure that the same Projects, Licenses & Propagation
rules which exist on master site are also created at all other replica sites.

If you are on Tc 11.6, Tc 12.0 or above, it is highly recommended to use TCXML based multisite
propagation as it has high performance compared to legacy multisite propagation. TCXML based
multisite propagation is the default setting in Tc 11.6, Tc 12.0 and above.

There is a setting TC_legacy_multisite_propagation preference to enable legacy multisite propagation

for release Tc 11.6, Tc12.0 and above, which is however discouraged due to performance reasons.

Propagation

1. If you are upgrading from Teamcenter version 11 to Teamcenter 11 or later, it is not required to
deploy "TC_DATA\model\propagation_preference_rules.xml” to Teamcenter DB as Teamcenter
11 and up is compatible with the new propagation framework.
2. If you are upgrading to Tc11.2.2 or up, please go through SFB-Teamcenter-8001528. Due to data Commented [KV(PLQQI1]: I think this should be
model changes to ProjectObjectRelation (POR) in Tc 11.2.2, there may be a need to migrate the mandatory to migrate propagation data after upgrading
from Tc10.1.x
legacy PORs to new style PORs. SFB-Teamcenter-8001528 provides details under what
conditions you must migrate the PORs. We highly recommend to migrate the legacy PORs to Commented [CK(SLCSSA2R1]: It is not mandatory. SFB--
Teamcenter-8001528 has conditions under which it is
new style PORs at the earliest. mandatory to migrate.
3. If you did not migrate the PORs, then whenever a new custom propagation rule is added for any
security group, make sure the same propagation rule is also added for “No Group”.
4. If you are on Tc11.3 or up and if you have propagation rules using "Fnd0TraversalCondition",
then please replace “Fnd0TraversalCondition” with isTrue condition. If you are at release Tc12.2

Unrestricted
 or up, you can replace “Fnd0TraversalCondition” with “Fnd0TraversalCondition2”. Do not use
“Fnd0TraversalCondition” for new propagation rules.
5. Do not use conditions which will perform checks on security attribute values (projects, licenses
etc) in propagation rules. The current propagation data model does not support this
functionality.
6. From Tc 11.5 onwards, creating propagation rules with Operation other than all “All” is not
supported in BMDE. The propagation rules defined with Operation other than "All" will be
deprecated in future. We recommend converting these propagation rules to Operation "All". If Commented [KV(PLQQI3]: I thought we stopped
you have a non-COTS rule defined with Operation other than “All’’, then first check if an supporting this, is it still supported?
equivalent propagation rule with “All” operation exists, if yes then delete existing propagation Commented [CK(SLCSSA4R3]: Yes, but there could be
rule. If not, then first create the propagation rule with “All” Operation and then delete the rules defined in earlier releases.
existing rule. Commented [CK(SLCSSA5R3]:
7. When a new propagation rule is added, or an existing propagation rule is removed, execute Commented [CK(SLCSSA6R3]:
update_project_data utility. If you are on Tc 11.6 or up, use update_propagation_data utility as
this is faster than update_project_data utility. Please “set AM_BYPASS=1” before executing the
utilities.
8. To disable propagation of any security attribute in Tc 11.x (fresh install or upgraded
environments), set the property constant “Fnd0PropagationGroup” value on the attribute to
“Propagation Disabled Group”.
9. Do not define any propagation rule with “Propagation Group” as “Propagation Disabled Group”.
10. Do not use “No Group” in “Fnd0PropagationGroup” property constant for any propagation-
enabled property. This Group is reserved for migrated data.
11. Do not define propagation rule with different styles but same security propagation group such
as
a. Rule 1 – Forward ItemRevision/Dataset/Security Group I/All/Merge
b. Rule2 – Forward ItemRevision/Form/Security Group I/All/Order

12. We recommend not to change the propagation group of any propagation enabled attributes.
If such requirements exist, please contact GTAC for further guidance.
13. We highly recommend using the Security Propagation Group with correct Style and Property
Type.
a. Merge style is recommended for Security Group I and for Multi-Value Property
b. Fill Style is recommended for Security Group II and Single-Value Property.
c. Order Style is recommended for Security Group III and Single-Value Property.
d. Overwrite Style is recommended for Security Group IV and Single-Value Property

14. Do not modify the propagation style of COTS propagation rules.

Note: If you change the style of propagation rule(s) for a security group, change the style in
TC_propagation_security_group_style preference as well. Please ensure that the Security
Group/Style used in propagation rules are matching with Group/Style defined in the preference.
15. Avoid creating propagation rules with generic Source type, Relation or Destination type.
For Example: -
If the requirement is to propagate project from Part Revision to Design Revision associated via Commented [KV(PLQQI7]: propagate
TC_Is_Represented_By relation, then define propagation rule as below

Unrestricted
 PartRevision - TC_Is_Represented_By - DesignRevision - Security Group I - isTrue - isTrue

Do not define generic propagation rule as below

ItemRevision - TC_Is_Represented_By - ItemRevision - Security Group I - isTrue - isTrue

16. Do not define propagation rule using “IMANRelation”. This relation is a parent of all the
relations. If the propagation rule is defined with this relation, then propagation will trigger for
every propagation action on the relations which may impact the performance.
17. Do not create propagation rules which creates circular propagation.
Example, COTS has “Reverse - Item – items_tag – Item Revision” propagation rule. If you create
propagation rule “Forward – Item Revision – items_tag – Item”, it will result in over propagation.
18. Propagation rules can be defined to propagate certain security attributes from a source object
to other destination objects. These rules are applied recursively and repeatedly and could
therefore potentially navigate to many different sets of objects. Rule sets that traverse across
consistent sets of data (islands of data) in a nested recursive manner, such as Item to Item
traversal, can create problematic propagation loops. A loop is said to be formed if traversal from
a business object type via propagation rules ends at the same business object type or a parent
or child of that business object type.
Propagation loops potentially generate a very large set of destination business objects. If this
occurs, then performance of user interactions and other Create/Read/Update/Delete (CRUD)
activities can be adversely affected.

Example Forward ItemRevision IMAN_specification Dataset

Forward Dataset IMAN_external_object_link ItemRevision

Unrestricted
 Blue line from Item Revision to Dataset indicates propagation within island of data; red line from
Dataset to ItemRevision indicates propagation outside island of data

Example Reverse Item items_tag ItemRevision

Forward ItemRevision IMAN_specification WorkspaceObject

The above propagation rule set forms a loop because the traversal starts from Item to
ItemRevision and then from ItemRevision to WorkspaceObject, which is a parent of
Item.

Example Forward WorkspaceObject IMAN_specification Dataset

Forward Dataset IMAN_external_object_link ItemRevision

The above propagation rule set forms a loop because the traversal starts from
WorkspaceObject to Dataset and then from Dataset to ItemRevision, which is a child of
WorkspaceObject.

Test the set of propagation rules

- If you are on Tc 12.2 or up, propagation_doctor utility is available which identifies
propagation rules with potential traversal risk. Please follow below steps.

Before deploying a new set of propagation rules to a production database, deploy these
rules to a test server containing all the propagation rules present on the production
database. Run the propagation_doctor utility to ensure that the rule does not create a
potential risk of a looping traversal.
If a potential looping traversal risk is identified, then the utility reports the combination of
propagation rules that create the loop. Use one of the following approaches to reduce or
eliminate the risk.

Note: For Tc 11.x and Tc 12.0 and Tc 12.1 releases, we plan to compile propagation
doctor utility and will upload to GTAC site in near future. Meanwhile you can manually
inspect the propagation rules for potential traversal risk and follow below remedies.

Remedy
Fix 1: Re-formulate the rule with more specific source/destination classes.
Fix 2: Navigate to the relevant destination objects from some other source objects.
Fix 3: Use custom post actions to populate the data, rather than a propagation rule.
Fix 4: Re-evaluate whether this particular propagation rule is required in the first place.

19. If you are on Tc 12.2 or up, please execute propagation_doctor utility to identify propagation
configuration issues. This utility is further enhanced in Tc 12.3 to identify and report more
propagation configuration issues. Please refer Teamcenter Documentation for more information
about this utility.
20. Do not modify ProjectObjectRelation (POR) objects. These are internal Teamcenter objects to
maintain propagation data.
21. Do not register extensions on ProjectObjectRelation as this is an internal helper object.
Extensions are not supported for this object.

Unrestricted
 22. Do not use setProject_list to
23. setProject_list and setLicense_list Teamcenter property operations to explicitly set project_list
and license list on WorkspaceObjects are obsoleted in TC11.3 and up. Please refer SFB -
PL8014278 for more details.

Unrestricted