Why did Jakarta change Application File field labels for "Customer update" and "Replace on upgrade"?

[maynartt]

We upgraded one of our instances to Jakarta Patch 1 Hotfix 1 (released 2017-07-18 according to the release notes) to test our current functionality in preparation for an upgrade, and I saw that the field labels on the Application File table (sys_metadata) for these fields changed:

Column name	Istanbul Column label	Istanbul's Label Updated (US Eastern)	Jakarta Column label	Jakarta's Label Updated (US Eastern)
sys_customer_update	Customer update	2015-06-05 00:01:51	Customer update (No Longer Used)	2017-03-17 13:43:57
sys_replace_on_upgrade	Replace on upgrade	2015-06-05 00:01:51	Replace on upgrade (No Longer Used)	2017-03-17 13:44:30

I am concerned by this (we definitely use them today), and I looked and looked in the release notes etc, and didn't see any reference to these fields, and what, if they are indeed no longer used, replaces their functionality.

I also looked to see if someone else manually updated these labels in our instance that we cloned the Jakarta instance from, and didn't see any.

Does anyone have the same on their Jakarta (same patch and hotfix) instance?   The bigger question is, does anyone know why these label changes were made?   If so, please explain or point me to it.

Thanks!

[maynartt]

I just wanted to add a point of clarity:

the values I show under these column headers in my previous post all come from the sys_documentation record associated with the sys_dictionary record:

1. Istanbul Column label
2. Istanbul's Label Updated (US Eastern)
3. Jakarta Column label
4. Jakarta's Label Updated (US Eastern)

FWIW - The funny thing is if you look at the sys_dictionary records in Jakarta, which have a "column_label" field, those values are the old values.

[maynartt · Accepted solution]

I received an answer for this from HI.   They verified the following process needs to be done before upgrades (scoped apps included, which is what we're concerned with):

What we do today in Istanbul…

If, on the application object (anything extended from Application File — sys_metadata) the Customer update value is true, and on the next application update we want to override that object, we'd bring up that object in the associated list, add Replace on upgrade as a column on that list, and change its Replace on upgrade value to true before running the application update.

What we'll do in the future once we upgrade to Jakarta…

The fact that the application object has an associated record on the Customer Update (sys_update_xml) file, it means that at some point in time an update was made to it in that instance. There is no longer a need for a "Customer Update" field. Therefore, for each one of those that exists in the sys_update_xml file that we want to override, we'll need to change its Replace on upgrade value to true before running the application update (meaning the replace_on_upgrade field on sys_update_xml, not the sys_replace_on_upgrade field on the application object).

The quote from the HI agent that worked on my incident concerning any documentation on this: "I verified and found that these two fields are in fact not available anymore on the sys_metadata table as per an internal KB."   I still can't find it mentioned in docs.servicenow.com.

I've copied below a matrix the agent sent me for further explanation.

sys_metadata.sys_customer_update	sys_metadata.sys_replace_on_upgrade	sys_update_xml exists	sys_update_xml.replace_on_upgrade	Outcome
ignored	ignored	yes	true	overwritten on new-family and optimized upgrades
ignored	ignored	yes	false	Preserved
ignored	ignored	no	not applicable	overwritten on new-family and not-optimized upgrades

[roy_dreijling]

Great, thanks for the confirmation!

On more related thing that I noticed is that 'active' flag value is still ignored/retained even though the item is upgraded.
But before Jakarta 'Replace on upgrade' was automatically set when only the active state was changed.

This is no longer the case, so if you deactivate an oob item, you have to make sure you manually set 'Replace on upgrade' as well.

Can anyone confirm this?

[hadyndickson]

This is invaluable thanks so much!!... I've been doing so much research on this since Helsinki to figure out behaviour and it's been driving me insane having so many different places to tick replace on upgrade (Even the payload of the customer update - the snapshot of the application file - contains the replace on upgrade flag). My main concern was retaining things as OOB for EVERY upgrade after reverting them but keeping customer updates for historical value, and not just having it replaced on upgrade once and then skipped in subsequent upgrades.

It seems like SN differentiate between family and sub-family upgrades (optimized vs not optimized)? I would like to know more about what determines that...

So does that matrix apply to Jakarta and higher?? Or has it been this way for a while?