Resolving Naming Conflicts


If you don’t impose a site-specific naming convention for Workspace items (queries, reports, charts, and so on), users and groups, and other stateless records, it is possible to have different objects with the same name.

For example, duplicate names can occur when user administrators at two sites within a clan add the same user name within a synchronization cycle. In this case, after the replicas are synchronized, two users have the same name.

Internally, ClearQuest ensures that records and Workspace names are unique:

Workspace Naming Conflicts and ClearQuest Web

If two Workspace items (queries, reports, and so on) have the same name, both items work as expected in the Windows and UNIX clients, according to mastership restrictions and database privileges. However, in ClearQuest Web, only one of the items works. To avoid confusion, you must rename one or both of the items.

Renaming Workspace Items

In order for you to modify a Workspace item, your current replica must master it. To determine which replica masters a Workspace item, open the Workspace, right-click the item, and click Mastership.

To rename a Workspace item:

  1. Right-click the Workspace item and click Rename.
  2. Type a new name in the highlighted area and click Enter.

Working with Ambiguous Workspace Items

If you need to use multiutil commands to work with a Workspace item with a naming conflict, you must refer to its keysite name, which is the name of the site where the Workspace item originated. For example:

"Workspace:\Public Queries\Project Report<keysite-name>" 

The following example uses the keysite name in the object selector:

multiutil describe -clan telecomm -site tokyo -family PRODA -user tokyoadmin 
-password secret "workspace:Public Folder\Project Report<boston_hub>"
Multiutil: Mastership of ‘workspace:Public Queries\Project 
report<boston_hub>’ is ‘boston_hub’.

Fixing Naming Conflicts for Stateless Record Types

To fix a naming conflict for a stateless record, you must rename one of the records.

Renaming Records

To rename a stateless record that has a naming conflict:

  1. Find the record in question. See Finding Stateless Records with Naming Conflicts.
  2. Change the name of the record. You must have mastership of the record to modify it.
  3. To rename a stateless record, you must modify a field that is used as the unique key for that record. To do this, use the action in your schema that allows you to modify records without changing their state.

  4. Synchronize the family.

Ensuring That a Record Is Unique

To ensure that a record is unique, stateless record types use the ratl_keysite field. The ratl_keysite field is an internal system field that stores the name of the site where an object was created.

For example, a new customer named NetInc is created at two replicas during the same time period between synchronizations. When each replica synchronizes, there appear to be two customer records with identical names. To ensure uniqueness, ClearQuest references the ratl_keysite field.

If you need to use describe or chmaster commands to work with an ambiguous record, you must refer to its keysite name (originating site name). For example:

customer:NetInc<keysite-name>.

The following example uses the keysite name in the object selector:

multiutil describe -clan telecomm -site tokyo -family PRODA -user masako -password secret customer:NetInc<boston_hub>
Multiutil: Mastership of ‘customer:NetInc<boston_hub>’ is ‘boston_hub’.

Finding Stateless Records with Naming Conflicts

You can use the ratl_keysite field in queries designed to find stateless records of the same name. Follow these guidelines when querying for stateless records with naming conflicts.

To assist you in viewing and modifying records, you can add the ratl_keysite field to the form of any stateless record type where you expect naming conflicts to arise. For more information, see the Administrator’s Guide for Rational ClearQuest.

Identifying User and User Group Naming Conflicts

To log on with an ambiguous user name, use the keysite name as part of the user logon name (for example, username<keysite-name>, where keysite-name is the site where the user was created). If you log on with an ambiguous user name without the keysite name, you get an invalid logon error. Clicking the detail displays the following error:

User name ’xxx’ is ambiguous; rename or qualify with ’<’SITE’>’ to 
proceed.

Renaming Users

In ClearQuest Designer, when you try to modify user information for a user who has a conflicting name, you get the following error message because of the < > characters in the name:

ERROR! The string value ("DupUser<SITE1>") is invalid: Names cannot 
contain one of these characters:! "#$%&’()*+,./:;<=>?@[\]^‘{|}~

You must rename the user. You cannot modify any user information, except the Name field, until the user has a unique name that does not include the < > characters.

You cannot rename or delete a user group.

To rename a user:

  1. Click Tools > User Administration.
  2. In the User Administration dialog box, double-click the user you want to modify.
  3. In the User Properties dialog box, modify the name of the user.
  4. Click OK.
  5. Upgrade the associated user database by clicking DB Action > Upgrade.
  6. In the Upgrade dialog box, select the user databases you want to upgrade.
  7. Click OK.
  8. Click OK.
  9. The administrator at the new master replica must upgrade the database after receiving the synchronization packet that contains the changes. For more information, see the Administrator’s Guide for Rational ClearQuest.

Using multiutil with Ambiguous Users and User Groups

If you need to use describe or chmaster commands to work with a user or group whose name is the same as another user or group, you must refer to their respective keysite name (originating site name).

Use the describe command to find out where the user is mastered. In this example, the keysite is the boston_hub replica:

multiutil describe -clan telecomm -site tokyo -family PRODA -user masako 
-password secret user:jsmith<boston_hub> 
Multiutil: Mastership of ‘user:jsmith<boston_hub>’ is ‘boston_hub’.