Customers who apply the workaround described in KB0529194 or who are running on Calgary Patch 4 or later will notice a change of behavior in the conflict checking for change requests. The workaround/fix for this problem means that any Maintenance Window record where the Applies to field is empty (None) will match with all Affected CIs where the change request is outside of the maintenance window.

Leaving the Applies to field as None should yield the opposite (not match with any CIs). To have a maintenance window match with any type of CI, the Applies to field can be set to Configuration Item [cmdb_ci].

Steps to Reproduce

  1. Log on to a Calgary instance running patch 4 or later.
    • For earlier Calgary instances, apply the workaround in PRB587670 (for more information, see the associated known error article KB0529194).
  2. Go to the Maintenance Windows module and use the New button to create 2 or more new records.
    Only the Name field needs to be completed.
  3. Navigate to Change > Create New.
  4. In the Configuration Item field, enter a value.
  5. In the Planned Start and Planned End date fields, enter a date and time.
    If you are viewing a tabbed form, these fields are on the Schedule tab.
  6. Save the change request.
  7. Click the Check Conflicts link.
    If the Conflicts related list is not on the form, right-click in the form header and use Personalize > Related Lists.

Note that the following message is displayed at the top of the form: '

There ARE CONFLICTS - See "Conflicts" related list. When you scroll down to this related list, there will be entries of type 'Not In Maintenance Window' for each of the Maintenance Windows that you created earlier.


To fix this issue, two changes must be applied to the ChangeCheckConflicts script include:

  1. Modify the buildAncestorClassInfo method. Replace the line var ancestorList = j2js(gru.getTables(key)); with var ancestorList = gru.getTables(key);removing the j2js call.
  2. Replace the _doesScheduleApplyToCi method with the following code:

_doesScheduleApplyToCi: function(scheduleAppliesToTable, ciTable) {
    return (this.ciClassAncestors[ciTable].indexOf(scheduleAppliesToTable)!=-1);

Related Problem: PRB591189

Seen In

Calgary Patch 3 Hot Fix 1
Calgary Patch 4
Dublin EA 1
Eureka Patch 5

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2015-12-10 19:18:53