Content Migration Manager > Product documentation

Configuring Teamcenter for the migration process (CMM 1921)

Content Migration Manager: Configuring Teamcenter for the Migration Process Version 1921

Software Copyright and Trademark Notices

© 2020 Siemens. All Rights Reserved. This software and related documentation are proprietary to Siemens Industry Software Inc. LIMITATIONS TO U.S. GOVERNMENT RIGHTS. UNPUBLISHED - RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. This computer software and related computer software documentation have been developed exclusively at private expense and are provided subject to the following rights: If this computer software and computer software documentation qualify as "commercial items" (as that term is defined in FAR 2.101), their use, duplication or disclosure by the U.S. Government is subject to the protections and restrictions as set forth in the Siemens Digital Industries Software commercial license for the software and/or documentation, as prescribed in FAR 12.212 and FAR 27.405(b)(2)(i) (for civilian agencies) and in DFARS 227.7202-1(a) and DFARS 227.7202-3(a) (for the Department of Defense), or any successor or similar regulation, as applicable or as amended from time to time. If this computer software and computer documentation do not qualify as "commercial items," then they are "restricted computer software" and are provided with "restrictive rights," and their use, duplication or disclosure by the U.S. Government is subject to the protections and restrictions as set forth in FAR 27.404(b) and FAR 52-227-14 (for civilian agencies), and DFARS 227.7203-5(c) and DFARS 252.227-7014 (for the Department of Defense), or any successor or similar regulation, as applicable or as amended from time to time. Siemens Digital Industries Software, 5800 Granite Parkway, Suite 600, Plano, Texas 75024.

Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

THE SOFTWARE IN THIS PRODUCT WAS IN PART PROVIDED BY GENIVIA INC AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

All other trademarks or registered trademarks belong to their respective holders.

Contents

Introduction .......................................................................................................................................... 3 2. Creating a Group, Role and User for CMM Migration .......................................................................... 3 2.1 Start Teamcenter and login as a DBA user (infodba) .......................................................................... 3 2.2 Add the Organization application to the Teamcenter Navigation Pane ............................................. 3 2.3 Launch the Organization application .................................................................................................. 4 2.4 Create the Migrator Role .................................................................................................................... 4 2.5 Create the CMM Group....................................................................................................................... 5 2.6 Create or Assign a User to the CMM Group ....................................................................................... 6 2.7 Add a New User to the CMM Group ................................................................................................... 7 2.8 Add an Existing User to the CMM Group ............................................................................................ 8 3. How to Create Access Manager Rules .................................................................................................. 9 3.1 Basic Use Case ..................................................................................................................................... 9 3.2 Preliminary Steps .............................................................................................................................. 10 3.3 Precedence ........................................................................................................................................ 10 3.4 Remove Access to Working Data ...................................................................................................... 11 3.4.1 Item Revision – Deny Working ................................................................................................... 12 3.4.2 Dataset – Deny Working ............................................................................................................ 15 3.5 Verify Updates .................................................................................................................................. 17 3.5.1 Verify Recently Applied Deny Read ........................................................................................... 17 3.5.2 Check Existing Permissions of Approved Objects ...................................................................... 19 3.6 Update Rules for Has Status ............................................................................................................. 20

Introduction

Content Migration Manager recommends best practice for controlling the migration process through Teamcenter. The best practices describe a process of establishing users, groups, roles and access rules to make sure only selected users can migrate data and that migrated data is not available to general NX users until it has inspected and approved for use. This document describes creating the necessary users, groups, roles and rule in Teamcenter. You must be a Teamcenter administrator to execute the steps described. 2. Creating a Group, Role and User for CMM Migration 2.1 Start Teamcenter and login as a DBA user (infodba)

Enter the User ID and Password for a DBA user in your Teamcenter environment. The infodba user account will be used for this example. 2.2 Add the Organization application to the Teamcenter Navigation Pane

When you first run Teamcenter, it will open in the Getting Started application. To create Groups, Roles and Users you will need to run the Organization application. The Organization application may not be accessible from the Navigation Pane if you haven’t added it previously. To add the Organization application to the Navigation Pane; go to the bottom-right of the Navigation Pane (A), click on the more icon (>>) then slide the cursor to the Add Applications selection and then up to the Organization ( ) application selection when the application list opens. Click on the Organization application selection to add it to the Navigation Pane.

2.3 Launch the Organization application

The Organization ( ) application is now accessible from the Navigation Pane. To launch the Organization application go to the bottom-right of the Navigation Pane, click on the more icon (>>) and then click on the Organization application selection.

2.4 Create the Migrator Role

Teamcenter Roles are created in the Organization application. For CMM, it is recommended that a Migrator role be created for the user account that will perform the migration. To create the Migrator role in the Organization application, select the Roles function (A). Enter “Migrator” in the Role name (B), “CMM Migrator Role” as the Role Description (C) and then press Create (D).

A B C D

2.5 Create the CMM Group

Along with the Migrator role, the CMM group is used during the migration process to own the in-process migration data. The Organization application is used to create the CMM group. Staying in the Organization application after creating the Migrator role, select the Group function (A). Enter “CMM” in the Group name (B) and “CMM Group” in the Group Description (C).

Click on the Default Volume button ( ) and select a default volume to use for the CMM group (D). In the List of Defined Roles, locate and select the Migrator role (E).

A B C D E

Click on the add button (+) to add the Migrator role to the List of Selected Roles for the CMM group. Click the Create button (F) to create the CMM group.

2.6 Create or Assign a User to the CMM Group

At this point, a user needs to be created or assigned to the CMM group for use with the Migrator role during migration. This is done in the Organization application. In the Organization list (top-left list in the Organization application) locate and select the Migrator role under the CMM group (A). Click the “Add User” button (B) to open up the Organization User Wizard.

There are two options for adding a user to the CMM group. An existing user in the organization can be added, or a new user can be created and added. First, adding a new user will be described, followed by adding an existing user. Both of these actions are done from the Add User button on the Migrator role form. F A B

2.7 Add a New User to the CMM Group On the Select User Option page of the Organization User Wizard, select the “Add new user to the group/role” option (A) and click Next (B). On the Specify New User page of the Organization User Wizard, create the new user by entering “cmm_user_1” in the Person Name, User ID, OS Name and Password fields (C). The Default Group should be “CMM” and the Roles set to “Migrator”. Leave the Default Volume and Default Local Volume set to “?” as these will be controlled by the settings in the CMM group. Licensing level is Author. Press “Finish” (D) when done filling out the form.

Once the cmm_user_1 User is created the Select User Option form will reappear. On the Select User Option form, press the Close button (E) to return to the Organization application. The Organization application will show the cmm_user_1 User as created under the Migrator role in the CMM group.

A B C D E

2.8 Add an Existing User to the CMM Group

On the Select User Option page of the Organization User Wizard, select the “Add existing user to the group/role” option (A) and click Next (B). On the Add Available User(s) page of the Organization User Wizard, select an existing user from the list of existing users to add to the CMM group (C). In this example, the eng_user1 user is selected.

After selecting the user from the list on the left, press the “>” button to move the user to the Selected Users list on the right. Press the Finish button (D) to add the selected user to the Migrator Role in the CMM group. Once the selected user is added the Select User Option form will reappear. On the Select User Option form, press the Close button (E) to return to the Organization application.

A B C D E

The Organization application will show the selected user added under the Migrator role in the CMM group. The default group for the added user will remain listed as the default group set when the user was created. Clicking on the Default Group button (F) will show the list of default groups for the user, in which, the CMM group will appear.

This completes the process of creating the CMM group with a Migrator role and adding a user to the group for use during CMM migration.

How to Create Access Manager Rules

The basic definitions for Access Manager in Teamcenter are contained in the online help section “Access Manager Guide”. It is possible to stop some areas of Teamcenter functioning if the ACL tree is updated and the following from the Access Manager Guide should be read and understood (the exact locations vary a little depending on the help version, these are for 10.1): Creating and managing rules -> Good rule practices Creating and managing rules -> Cautions for using rule trees

3.1 Basic Use Case

The business requirement outlined here is for the role Observer in any group to have access to Item Revisions and Datasets that are at Approved status only. Item access is open. The following outlines a method – it should be noted it is not the ONLY method – there are a number of different ways to achieve this. The method used here tries to keep the Out Of The Box (OOTB) settings, where a change is required an additional rule is added that overrides the original to give the required result. If the OOTB rules are to be updated the best practice is to replace with a new rule named appropriately. E.g. _, GTAC_Working for example. 3.2 Preliminary Steps

Before any update the ACL tree should be exported as a back up.

3.3 Precedence

It is critical to understand the precedence. The higher up the branch, the greater precedence. For example:

The Has Bypass, Bypass ACL (rule 1 in the snapshot) will over ride any rule beneath it. The Owning Group Has Security External, External Data ACL (rule 2 in the snapshot) will override or take precedence over the Has Class POM_application_object, Working ACL (rule 3 in the snapshot) Within a branch the sub branch will take precedence or override the parent. Children have more control than parents!!!! For example: If the POM_application_object, Working ACL (rule 1 in the snapshot) would apply (i.e. if it is not over ridden by one higher up) then if the object is a working ItemRevision 2 will override 1 because 2 is a child of 1. BUT 3 and 4 are children of 2, so will override 2. Within a sub branch where the entries are the same level the precedence returns to the higher up, the greater precedence. 3 is higher than 4. In this case if the object is a working Item Revision then rule 3 has the greatest precedence. 3.4 Remove Access to Working Data

In the use case the Observer role should have no access to Item Revisions or Datasets. As stated this is simply a possible method to achieve this there are a number that you can use. This method tries to use the existing structure and avoid updating or replacing OOTB entries, but this is simply a choice – not necessarily a restriction. In this method we will add entries beneath the ones for the class within the “Working” part of the structure to deny the access to working (objects with no status applied).

3.4.1 Item Revision – Deny Working

So Add an entry for ItemRevision under the ItemRevision class in working and another entry for Dataset under the Dataset class:

Steps Required: • Back up the ACL tree before the update • Select the Has Class(ItemRevision) from the POM_application_object, Working section

• The Condition and Value can be retained because the deny applies to any object of the class • Enter an ACL name for the new rule • Select Create (the yellow  on the right of the ACL Name)

• Select the + add entry button (see below) • Click in the Accessor Type box to access the list. Select Role. In this case the rule needs to apply to a user in that role regardless of their group, therefore the Role option is most appropriate

• Click in the Accessor ID box to access the list, select the role, in this case Observer

• Best practice is to set the fewest number of Access Privileges to avoid duplication and confusion, in this case denying read should be enough. If you can not find the object because you have no read access, how can you update it. However, this may not take account of all of the ways a user can access data indirectly, including via custom code. If you have and Out Of the Box rule you will find that write, delete and change may be granted. In most cases customers deny all of these. Note also at 10.1 it will suggest denying export (via a pop up) when read is denied. However, export is normally controlled higher up the ACL tree, so denying here will not have any affect.

• Saving – it should be noted there a number of places you need to save / add the entry: o Save the ACL itself

o Add the ACL to the tree

o Before the ACL tree is saved the location of the ACL rule may need to be adjusted. In this case the existing child entries do not affect read or write access, however, if the intent is to apply this to all ItemRevisions then maybe placing at the top of the list best indicates the intent. Moving the rule up in this case is Optional

o Save the ACL tree

3.4.2 Dataset – Deny Working

• Select the Has Class(Dataset) from the POM_application_object, Working section • The Condition and Value can be retained because the deny applies to any object of the class • The ACL created for the ItemRevision can be reused, so it can be selected from the list

• ADD the ACL to the tree (DO NOT select modify or you will update the OOTB entry!)

• Move the entry to the top of the list so that it takes precedence, it should be moved from the bottom to the top of the list

• Save the updates

• NOTE that ACL changes are not propagated to active sessions. The session you are logged in to will see the new change but any other users will have to log out and then log back in to see the update

3.5 Verify Updates 3.5.1 Verify Recently Applied Deny Read The updates can be verified as a dba user from my Navigator • Select an Item Revision which is working (no status) • Select View -> Access (or via right mouse key menu or 3MB)

• Select a user that is in the target role • This will show a summary of the permissions, in this case read is granted • To check the ACL that grants or denies a permission select the i button.

• The details show that the read access is granted due to the fact that the object is owned by infodba

This is a system ACL that ensures templates and other system objects are always accessible. It indicates an import element – you should always check permissions using standard data!

• So an object is selected that is owned by a standard user then the permission rechecked it can be seen that the user has no read, write, change or delete. And these are denied by the ACL we added.

3.5.2 Check Existing Permissions of Approved Objects

Before the updates are made to allow read if the object is approved the default rules are verified. Making sure the object is not owned by infodba to check permission. In this case it is an object with the same owning group as our test user. Select an Approved Item Revision and verify the how the permissions are set.

This would appear to be correct, however if a Revision with a different status is checked this will give the following:

The Has Status rule has no specific status set therefore it applies to all statuses. Therefore an addition needs to be made so that the Observer role may only see the Approved objects

3.6 Update Rules for Has Status

This has to be done in two stages; the Observer role needs read removed for all statuses. Then the Observer role needs read to be added back where the status is Approved. As before there are number of ways this can be done, particularly for the deny. The deny could be added to the OOTB rule Vault. But in this example the approach is avoid updating or replacing any OOTB rule, again this is a choice not a requirement. As seen in section 0, the rule that currently applies to an object with a status is Has Class (POM_object) – Has Status(), ACL Vault.

Children take precedence over parents. Therefore if a rule is added under the OOTB rule it is possible to override the OOTB permissions. To remove the access: • Select Has Status() -> Vault • Leave the conditions as they are and enter a new name • Select create • Select the + to add a line and update so that Role Observer is denied Read access (only select what is required, the user has no write because of the world line in the Vault entry) • Select the save icon to save the ACL

It is possible to use the ACL created for working but this does deny write which is not required – it’s a small thing, up to the business to decide. • Select Add

• To add the permission to allow the observer to read Approved • Select Has Status() -> Vault • Leave the condition Has Status but set a value of Approved • Select create • Select the + to add a line and update so that Role Observer is granted Read access • Select the save icon to save the ACL

• Select Add

Once the rule is added you need to consider the precedence of the rules. As it stands because the highest rule at the same level will take precedence, the observer will not have read access to any status. The rule that re-applies the read access for the Approved Status must be moved up above the rule that denies all status.

• With the GTAC_Observer_Grant_Read selected use the green arrow to move the entry up • Select save to commit all of the updates to the tree

Only the current client session will be aware of the updates, other users must log out and in to use the new ACL tree. The permissions can then be verified as per section 0. Approved Revision

Rejected Revision

Source: CMM 1921 download (Support Center PL20201112075217794, CMM1921.7z), NXMigration/Documentation/cmm_1921_Configuration.pdf · retrieved 2026-10-02