Fix script change for dictionary attribute not applying after upgrade

[Darren Codipill]

Hello, I have a fix script that is intended to change a dictionary attribute (from sys_schema_attribute_m2m table) value after upgrade. When testing out the script using the "Run fix script" option it works as intended, and when testing it out on TD upgrade scenarios it is correctly updating the value based on log values for gr.update() (see 'Log messages' photo). However, for some reason the value gets overriden by the system restoring it to its original value around 15 minutes after the upgrade is finished (see 'Dictionary attribute' photo). Record for rollback has been set to false. I have looked at upgrade and localhost logs and cannot seem to find anything unusual there. Does anyone have any ideas what the issue might be?

Script (log statements are there for testing purposes): 

fixARIntent();

function fixARIntent() {

    gs.info("Executing IAR Fix Script: Starting to update value of ar_intent to support custom intents.");

    var intentGr = new GlideRecord('sys_schema_attribute_m2m');

    intentGr.addQuery('schema.column_label', 'Auto-Resolution intent');

    intentGr.addQuery('attribute', 'f330f130b3030300f7d1a13816a8dc13');

    intentGr.query();

    if (intentGr.next()) {

        gs.info("Executing IAR Fix Script: intentGr.canWrite() is: " + intentGr.canWrite());

        gs.info("Executing IAR Fix Script: The sys_id of the ar_intent record is: " + intentGr.getUniqueValue());

        intentGr.setValue('value', 'new  AutoResolutionIntentChoiceListBuilder().getSupportedIntents(current.ar_configuration.sys_id);');

        intentGr.update();

        gs.info("Executing IAR Fix Script: The update value of intentGr.update() is: " + intentGr.update());

    }

}

[Tony Chatfield1]

Hi, have you checked that the upgrade has not updated existing ACL for the value field and this is preventing write?
In a PDI, I return 1 record for your intentGr query with a sys_id that is different to the one in your log messages

IE 913da01f97c31110f079fb000153afc2

Perhaps you potentially have 2 or more records returned by your query and the fix script 'if next' means only the first record is updated?

[Darren Codipill]

Hi Tony, thank you for your response. If you look at the log messages there is one for intentGr.canWrite() which indicates whether writing to the record possible. Since this value returns true, we know that there cannot be an ACL that is preventing us from writing to the record. 

For your point regarding the sys_id, the sys_id on your PDI could be different than the one that is on my instance. However, the other fields that are added to the query only point to one unique record. There are no other records that have 'schema.column_label' as 'Auto-Resolution intent'

[Tony Chatfield1]

Hi Darren, my understanding intentGr.canWrite() will assess the record and not fields within the record unless you specify them, and it is field level that you need to evaluate IE

var test = new GlideRecord('task');
gs.info(test.canWrite());
gs.info(test.sla_due.canWrite());

With regard to the sys_id, normally I expect to see SNC generated\sourced records with the same sys_id across platforms, but I am sure there are exceptions.

[Darren Codipill]

Hey Tony, thanks for the tip. The value of the 'intentGr.value.canWrite()' ended up being true as well so don't think that is where the issue lies