SCM changesets should not be checked if a component baseline is replaced with a newer one

Impact of the Work Item Link/Comment Precondition on Replace Baseline

We are using the Jazz SCM precondition that requires a work item link and change set comment before a change set can be delivered to the server (see Precondition.to.deliver.changesets.png). This precondition works as expected during the delivery of change sets.

However, after enabling this precondition, an additional check is also activated during the Replace Baseline operation. This behavior is neither visible in the configuration nor documented from a user perspective.

According to IBM, when a component version is replaced with another component version, the system validates the consistency of all change sets that are introduced by the baseline being selected:

• Replacing an older baseline with a newer baseline triggers validation of the newly introduced change sets.
• Replacing a newer baseline with an older baseline does not trigger the same issue because no additional change sets are introduced.

As a result, the Replace Baseline operation can be rejected even though the baseline itself is already a frozen and previously accepted configuration.

Scenario 1: Different Project Areas for SCM and CCM/Jira

Consider the following setup:

• Project A contains the source code in EWM SCM.
• Change sets in Project A are linked to EWM CCM work items or Jira issues.
• A baseline is created from these change sets.
• The baseline is later reused in Project B by replacing a component baseline.

The problem is that the user performing the Replace Baseline operation in Project B must not only have access to the SCM artifacts from Project A, but also to the CCM/Jira project area where the linked work items reside.

If the user lacks access to the CCM/Jira project area:

• The work item links on the change sets are not visible.
• The Replace Baseline operation fails because the validation reports missing or invalid work item links.
• Other users with broader permissions may be able to perform the same operation successfully.

This behavior is confusing because Replace Baseline is an SCM operation on an already established baseline. It is not obvious why access to the originating change management project area should be required.

Scenario 2: Baselines Created Before the Precondition Was Introduced

Another problem occurs when the precondition is introduced after development has already been ongoing.

For example:

1. Baseline BL1 and BL2 were created before the precondition existed.
2. Some change sets within these baselines have no work item links or comments.
3. The precondition is enabled at a later point in time.
4. Users subsequently attempt to replace BL1 with BL2.

Although both baselines were valid when they were created, the Replace Baseline operation may now fail because the newer baseline introduces change sets that do not satisfy today's precondition requirements.

In other words, historical baselines are retroactively affected by a rule that did not exist when they were created.

As illustrated in Precondition.to.deliver.changesets.png, replacing BL1 with BL2 may fail, even though BL2 is a frozen configuration that was already accepted and used previously.

Why This Is Problematic

From a user perspective, the behavior is difficult to understand:

• Replace Baseline appears to be a simple SCM operation.
• Failures depend on historical change set metadata and user permissions that are unrelated to the current SCM activity.
• The problem may affect only certain users, making diagnosis even more difficult.
• Users have no clear indication why a particular baseline can or cannot be used.

This leads to:

• Additional support effort to analyze failures.
• Increased training effort to explain the behavior.
• Loss of confidence in the Replace Baseline functionality.
• Workarounds such as deleting and re-adding components instead of using Replace Baseline.

Requested Improvement

We would like the validation checks for work item links and comments to be enforced only when change sets are delivered, which is the original purpose of the precondition.

When a baseline is used in a Replace Baseline operation, it represents a frozen configuration that has already been created and accepted. Revalidating all contained change sets introduces unexpected dependencies on:

• Access rights to external CCM/Jira project areas.
• Current precondition rules that may not have existed when the baseline was created.

Therefore, we would like the ability to disable these additional consistency checks during Replace Baseline operations, or for Replace Baseline to use the already approved baseline without revalidating the contained change sets.