Linking RITM to Standard Change

[brianlan25]

Back in 2022 when we went like with change we created a file on the sc_req_item table called u_change_request. We then created a UI action to create a standard change with the following code.

// will redirect user to create a standard change and will fill the u_change_request custom field.
action.setRedirectURL(new StdChangeUtils().getURLForTask(current, 'u_change_request'));
 
action.setReturnURL(current);

Recently we got Yokohama Patch 13 Hotfix 4 and this suddenly no longer works. Any idea on what my we causing this? Note that I noticed that action.setReturnURL(current) is not in the code for the same UI action on Incident so I have tried to comment that out that code as well. Note that this is still working on incident the only difference is that incident is using the out of the box rfc field.

Edit: This note about it working on incident was wrong. The ATF template for incident that I copied was not validating that change number was associated to the incident. Since the incident test did not fail I thought it was working for incident.

[wiliamw]

Hello,

When you call new StdChangeUtils().getURLForTask(current, 'u_change_request'), the system dynamically checks the reference field provided in the second argument. In older versions, the platform was more forgiving with custom reference fields on tables outside of the core Task/Incident structure. However, recent patches have hardened the out-of-the-box (OOTB) Standard Change processor to explicitly look for the standard, native rfc relationship field when mapping standard changes from a task record. Because your Requested Item (sc_req_item) table relies on a custom field (u_change_request) rather than the native rfc field, the Script Include's internal field-validation logic now fails silently or rejects the target mapping, breaking the redirect URL generation.



Best Regards

[brianlan25]

I think it is more than that. I tried using the out of the box parent field in the script and it still will not work. It is almost more like the its not allowing it from tables.

[Shiny-Syslabo]

This appears to be a bug in the current version patch.

Upgrading to Zurich or later should resolve the issue.

The deadline for upgrading to the Australia version is the end of August.

If the upgrade is not completed by then, a forced version upgrade will be applied.

Please make sure you don't miss the deadline!

Also, if you'd like to resolve the issue as quickly as possible, please try the following workaround:

Option 1: Move Logic to a Business Rule (Recommended)

Since the patch restricts passing custom fields via URL parameters (sysparm_target_field), the best practice is to clear the parameter in the UI Action and use a Business Rule to link the records upon creation.

1. Update the UI Action Script: Remove the custom field from the URL generator.

JavaScript

action.setRedirectURL(new StdChangeUtils().getURLForTask(current, ''));
action.setReturnURL(current);

2. Create a New Business Rule:

• Table: Change Request (change_request)

• When: After / Insert

• Condition: Parent.Task type IS Requested Item

• Script:

JavaScript

(function executeRule(current, previous /*null when async*/) {
    var ritm = new GlideRecord('sc_req_item');
    if (ritm.get(current.parent)) {
        ritm.u_change_request = current.sys_id;
        ritm.update();
    }
})(current, previous);

---

Option 2: Add Custom Field to the Whitelist

If you prefer to keep the current UI Action logic, you need to bypass the new security restriction.

• Check System Logs: Click the UI Action and check System Logs > All for "Access Denied" or "Invalid Target Field" warnings.

• Update System Property: Look for standard change allowlist properties introduced in recent patches (such as sn_std_change.allowed_target_fields) and add u_change_request to the comma-separated list.

[brianlan25]

If I call the UI Action and don't send a parameter for the field all I get it undefined message after clicking on it.

I found no system property as you mentioned.