1196 views

Description

A regression added as part of a fix creates a condition where a Unique Key violation error occurs when adding and/or importing a group into a domain separated instance.  The regression was introduced in Helsinki Patch 10, Istanbul Patch 6, and Jakarta.  Upgrading to these releases exposes the instance to the defect.

During the upgrade, group data might be unavailable to users in non-global domains.  The regression causes the group table to temporarily be used as the domain table. When that occurs, the path data for groups is recalculated, causing it to be unavailable to users not in the global domain.  Group data will be unavailable until the upgrade corrects the domain table and the path data for groups is corrected.

Steps to Reproduce

 

 

  1. In a domain separated instance, create multiple users and groups.

    For more information, see the product documentation topic Groups.

  2. Upgrade the domain separated instance to Helsinki Patch 10 or Istanbul Patch 6 or Jakarta, from any version Helsinki or later.

  3. Import a set of groups with similar values as existing group records.

    Note the following error:

    Unique Key violation detected by database (Duplicate entry '!!!/' for key 'sys_domain_path')

    As a result of the error, the new groups cannot be imported.

 

How to determine whether you are at risk

Criteria for affected customers:
  • DEFINITELY AFFECTED
    • Domain MSP plugin (ID: com.glide.domain.msp_extensions) is activated.
    • The domain table is something other than "domain" (for example, Group, Department).
  • POTENTIALLY AFFECTED
    • Domain (com.glide.domain) plugin is activated.
    • The sys_mod_count value is 0 for the sys_user table’s sys_domain field.

Run the script snippet below in Scripts - Background before upgrading to an affected build.

  1. Copy the provided script snippet.
  2. Navigate to Scripts - Background and run the code.
    You should receive one of the following two outputs:
    • "Safe to upgrade" – The instance was not or is no longer at risk for the regression, and it is safe to upgrade.
    • "Cannot apply pre-upgrade workaround" – The instance will be affected by the regression after the upgrade. Please see the Workaround section for additional instructions.

Note: The workaround before you upgrade is different from the workaround post upgrade.  If you have already upgraded and are affected by this problem, see the Workaround section for additional instructions.

var dictGR = new GlideRecord('sys_dictionary');
dictGR.addQuery('name', 'sys_user');
dictGR.addQuery('element', 'sys_domain');
dictGR.setWorkflow(false);
dictGR.query();

// If the outcome is "safe to upgrade," the instance was not or is no longer at risk for the regression
// If the outcome is "cannot apply pre-upgrade workaround," the instance will be affected by the
//     regression after the upgrade

if (dictGR.next()) {
	var modCount = dictGR.getValue('sys_mod_count');
	var domainTable = dictGR.getValue('reference');

	if (modCount > 0) {
		if (!pm.isActive('com.glide.domain.msp_extensions')) {
			gs.print("Non-MSP customer with mod count > 0, safe to upgrade");
		}
		else if (domainTable == 'domain') {
			gs.print("MSP customer with mod count > 0 and domain as the domainTable, safe to upgrade");
		}
		else {
			gs.print("MSP customer with mod count > 0 and NOT domain as the domainTable, cannot apply pre-upgrade workaround");
		}
	}
	else {
		if (pm.isActive('com.glide.domain.msp_extensions') && domainTable != 'domain') {
			gs.print("MSP customer with mod count <= 0 and NOT domain as the domainTable, cannot apply pre-upgrade workaround");
		}
		else {
			dictGR.setValue('sys_mod_count', 98765);
			dictGR.setWorkflow(false);
			dictGR.update();
			gs.print("Updated mod count to 98765, safe to upgrade");
		}
	}
}
else {
	gs.print("No entry for sys_domain field on sys_user table sys_dictionary, safe to upgrade");
}

If you receive one of the following two print statements after running the script, contact Customer Support to implement the workaround post upgrade:

  • "MSP customer with mod count > 0 and NOT domain as the domainTable, cannot apply pre-upgrade workaround"
  • "MSP customer with mod count <= 0 and NOT domain as the domainTable, cannot apply pre-upgrade workaround"

Workaround

Only customers with Domain Support enabled are likely to experience this issue. If you believe you have encountered this issue following a recent upgrade, contact ServiceNow Customer Support to receive the available workaround.

 


Related Problem: PRB1073031

Seen In

Helsinki Patch 10
Helsinki Patch 11
Helsinki Patch 11a
Istanbul Patch 6
Istanbul Patch 6a
Jakarta

Fixed In

Helsinki Patch 11b
Istanbul Patch 6b
Istanbul Patch 7
Istanbul Patch 8
Jakarta Patch 1
Jakarta Patch 2
Kingston

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2017-12-13 09:00:17
Published:2017-07-26