[slarsen]

I’m growing increasingly frustrated with 2.0. I have a user-event before load where I use the form object in before load to add a sublist dynamically (call it ‘custpage_sublist’). It works fine. When I’m in the record UI, I see the list, I add line items, etc. I have a before-submit event where I want to read what was added in the lines. If I stringify the newRecord object in the ScriptContext, I can see the property “sublists” and I see my dynamic sublist and the lines and values. But I can’t for the life of me figure out how to read this.

When I try and get a line count (newRecord.getLineCount({sublistId: ‘custpage_sublist’)) it always returns -1 which means there is no such list. If I attempt to call getSublistValue on one of the line columns I know is there, it returns undefined. But I can see the data when I stringify the record object. What the heck am I not doing right here? Am I missing something or is 2.0 just simply nowhere near ready for prime time and waste of time to move our code to? Frustrated…
This is a cached copy. Click here to see the original post.

[erictgrubaugh]

I don’t feel it’s ready to move stable 1.0 code to. If 1.0 is working and serving your needs, keep it that way. For newer small tasks, or for something that only 2.0 supports (map/reduce, sftp, etc), then try it out. Personally I am not yet seeing behavioural parity in 2.0.

---

slarsen replied on 01/28/2017, 08:31 AM: Yes, I’ve come to that conclusion as well. Shame on me for thinking it would be further along than it is after several releases now. Expected to find bugs but not wholesale missing functionality like dynamic sublists.

[j.j]

i think this is more of an implementation issue than coding, in case you are populating sublist using script you can store the values in variables, in case some values are getting input in real time you can write client script, else you will be able to get the values post submit, we have plenty of such scenarios working already.

[MChammaTX]

Originally posted by j.j

View Post

i think this is more of an implementation issue than coding, in case you are populating sublist using script you can store the values in variables, in case some values are getting input in real time you can write client script, else you will be able to get the values post submit, we have plenty of such scenarios working already.

Not sure how this is an implementation issue. Granted you may be able to do it in an aftersubmit if you don’t care about the performance hit of loading and submitting. Seems like this is more of a NetSuite issue in supporting custom script ui in before submit.

[slarsen]

The issue is not an implementation issue nor a client-side issue. All that works just fine. The issue is at the submit event (before submit specifically) when you want to read the values that have been set on the client side. Setting them in yet other variables seems strange but perhaps misunderstanding. Haven’t looked at it in a while so suspect it will fix itself eventually. Since we know we can see our info on a submit event by stringifying the newRecord object, we wrote a little class that mimics the properties and methods of the sublist and parses this stringified version of the sublist so we have a graceful fallback. If it continues to be broken/not implemented, then we apply our class, otherwise we pass through to the (once working) NetSuite object. Code downstream uses the same methods so continues to work in the future once it gets fixed (might even be fixed, I don’t know).

[chanarbon]

Hi slarsen

Kindly file a support case for this concern so that we would be able to work on the mentioned concern on our end in NetSuite.

[mattdahse]

I strongly doubt that this would work in SS1.0 either. Adding a custom sublist by manipulating the form does not add any space in the database to store the data. The beforeSubmit event newRecord exists to contain what will be sent to the database, and nothing in your custom sublist has a place to go there.

Perhaps you should create the sublist by creating custom child records, and then the custom sublist would be included in the information being sent to the database.

---

slarsen replied on 04/01/2017, 04:26 PM: So there are times where parent/child record makes sense and times where dynamic sub-lists make sense. This is not a design issue though. All dynamic fields and lists are available in before submit and after submit. Am very aware you can’t “save” a dynamic field/list to the database and that also is not the issue we reported. I think you’re misunderstanding (or focusing on the wrong thing). We are simply creating a sub-list in before load which then appears in the UI. User enters data in the sublist. They submit it the form/record. We read this list data in before submit to launch other processes and set other real fields based on the contents of the list. Done. We have plenty of existing 1.0 code where we do this, so yes, it does work in 1.0. We were attempting to port this existing 1.0 code to 2.0. The same functionality in 1.0 code (reading sub-list data in before submit) didn’t work in 2.0 (unless its been fixed since we first reported it). That’s the issue we are reporting.

[Author]

Posts