1. Using Siebel Tools
  2. Open Inactive Conflicts

Open Inactive Conflicts

An object inactive conflict occurs when the target/child Workspace being rebased changes an object that is inactivated in the source/parent Workspace. This type of conflict will occur if any object above the modified object in the repository hierarchy is inactivated in the parent Workspace. For example, if a user changes a Business Component field and the containing Business Component itself was inactivated in the parent, then this conflict will arise.

You can either ignore this conflict or resolve this conflict by checking the Override option for the Inactive attribute.

For example:

  • Both User1 and User2 are working on changes for an upcoming release being developed in the IWS int_January. Each user creates a Developer Workspace under int_January\0 as dev_user1_Workspace and dev_user2_Workspace.

  • User1 inactivates the Contact Business Component and delivers this change to the parent IWS, creating a new version int_January1.

  • User2 modifies the Account Status Field by making it force active and then tries to deliver the change to int_January, but the system enforces a rebase.

  • On rebase, the merge process detects that the changes on the Account Status Field are no longer applied as the parent Contact Business Component is inactivated. Hence a conflict is logged against the Contact Business Component and the corresponding inactive attribute.

To resolve the conflict, select the Override option for the inactive attribute on the contact Business Component.

About Overriding Name Conflicts for Tasks

For Task UI workflows, resolving (or overriding) name conflicts is slightly different. Where there is a name conflict and the user chooses to override the conflict, then the parent record is suffixed with -old:0 and the record status changes to inactive. For example:

  • Suppose that User1 and User2 are working on changes for an upcoming release being developed in the IWS int_January. Each user creates a Developer Workspace under int_January\0 as follows: dev_user1_Workspace and dev_user2_Workspace.

  • User1 creates a new task named Create Account and delivers that change to the parent IWS, creating a new version int_January\1.

  • User2, who is unaware of User1’s changes, also creates a new task with the same name (Create Account), tests it, and attempts to deliver it to int_January.

  • User2's changes cannot be delivered because this is a non-trivial merge and it requires a rebase.

  • During rebase, the merge process by default detects that there is a name conflict so it renames the object in dev_user2_Workspace to Create Account-[Rebase].

Suppose User2 wants to retain the Create Account record they created. In such a case, User2 can select the Override option for the attribute (click Workspace menu, select Merge Reports, and go to the Attribute Differences-Critical Conflicts section – for more information, see Viewing Information About Merge Conflicts and Resolutions). As part of the override in this case:

  • User1's record is renamed to Create Account-old:0.

  • User1's record status changes to inactive.

  • User2's record remains the same.