Have an interesting issue pop up from 2025.1 - on Assembly Builds now, the components now have a soft requirement* of a department field (internal ID: 'class'). I've been charged with creating a script to get around this, by having a client script take whatever value is in the Header department field (internal ID: also 'class'). I'm testing it and it seems to throws me an error that makes me think that because I'm effectively causing an infinite loop by updating another 'class' field: "RangeError Maximum call stack size exceeded" Note that when I add the ignoreFieldChanged flag on the setCurrentSublistValue, nothing happens, all things equal. Anyone ever stumble into any situation like this? /**  *@NApiVersion 2.1  *@NScriptType ClientScript  */ define(['N/error', 'N/search'], function(error, search) {     function fieldChanged(context) {         let currentRecord = context.currentRecord;         let fieldName = context.fieldId;         let location = currentRecord.getValue('location')         let dept = currentRecord.getValue('class')         let item = currentRecord.getValue('item')         if (location && dept && item && fieldName === 'class')         {             console.log('made it in')             for (let i = 0; i < currentRecord.getLineCount('component'); i++)             {               currentRecord.selectLine({sublistId: 'component',line: i});               currentRecord.setCurrentSublistValue('component', 'class', dept)               currentRecord.commitLine({sublistId: 'component',line: i});             }         }     }         return {fieldChanged} }); *By soft requirement I mean that it gives you a popup saying to add a Department to the components, instead of having a little orange asterisk by it.

you're triggering on a field change, and in the fieldChange function you're .. changing fields

When does the popup occur? You can potentially move this to another entry point and/or refine your guard condition accordingly

@Anthony OConnor when I add that flag, as I said, the script does nothing.

if (context.sublist) return;

should work

@erictgrubaugh this happens when you try to save the AB

so you should be able to do it on a before submit UE

@Anthony OConnor let me play around a bit with what you suggested and I'll let you know what works.

Then I might suggest moving this code to

validateLine

or potentially to

saveRecord

. @Anthony OConnor’s suggestion to include

context.sublistId

in your guard condition is a good one.

@Anthony OConnor the sublist recommendation works perfectly.

So does the user have to fill out all the lines first, then go back and fill in the body-level

class

?

@erictgrubaugh other way around

I must be missing something. This code looks to me like it only gets through the guard when the body-level

class

changes

@erictgrubaugh that's what we want.

he's saying if you set the class first, then it runs and sets the lines... if you add the lines after then it won't run and update the newly added lines

My knowledge of the manufacturing records is poor though, so I don't know the typical flow for filling out an AB

yeah I'm not super familiar with ABs either... the other option would be a validateLine entry point

@erictgrubaugh the AB record you have to select a subsidiary, a location, and an assembly to build. When you select the assembly, natively it autopopulates all the components for whatever BOM revision it's defaulted/manually chosen

Got it, so no need to worry about lines being added afterward

Right. You can't do that like you would on say a Sales Order.

Makes sense, glad it's working