[slarsen]

I’m noticing that custom field types that are checkboxes are inconsistent in terms of how they accept or read values:

For example, on a custom record, if I have a custom field “custrecord_mycheckbox” setup as a checkbox, then 2.0 says I must set this (and assume read) as a boolean:

record.setValue({fieldId: “custrecord_mycheckbox”, value: true});

and

record.getValue({fieldId: “custrecord_mycheckbox”}); returns true or false

If I attempt to do set this using ‘T’ or ‘F’ like with 1.0 methods, I get this error:

You have entered an Invalid Field Value T for the following field: custrecord_mycheckbox

However, if I add a dynamic field in beforeLoad to the record “custpage_mycheckbox” and type it as a checkbox, and I try and set the defaultValue using boolean, I get this error:

{“type”:”error.SuiteScriptError”,”name”:”INVALI D_F LD_VALUE”,”message”:”You have entered an Invalid Field Value true for the following field: custpage_mycheckbox”

When I attempt to set the dynamic field using setValue with a boolean, nothing happens (no error). However, when I read the dynamic field:

record.getValue({fieldId: “custpage_mycheckbox”}); it returns string T or F (not true or false)

Appears that dynamic fields of type checkbox expect a ‘T’ or an ‘F’ (like 1.0 API methods) and NOT a boolean.

This is incredibly inconsistent between fields of the same type not to mention error prone. Would probably be best to make these consistent.
This is a cached copy. Click here to see the original post.

[CREECE]

Dynamic mode is as if you were in the UI which still returns T/F which makes sense. There IS a bit of an inconsistency but if you think of it that way it may help.

[slarsen]

I’m not following how it makes sense just because you’re in the UI. The same is true for non-dynamic fields. Dynamic fields are just not saved. In any case, it’s like going back to the early days when a checkbox would return ‘T’ or ‘Yes’ , ‘F’ or ‘No’ depending on where/when you were calling it and you had to write code to check for both if you wanted your code to be reusable. We use both the dynamic and regular fields in conjunction with each other – setting/getting each other is very common (e.g. nlapiSetFieldValue(‘custrecord_mycheckbox’,nlapiGe tFieldValue(‘custpage_mycheckbox’) || ‘F’), so v2 kind of breaks that process as we now have to convert back and forth.

Imagine having a method isChecked: function(name){…}. So you now have to check if the name starts with ‘custpage’ or check the type of the response to see if it’s a boolean or string? Just more code, more error prone, etc. I’m more for consistency (and a common approach).

[slarsen]

OK, I’m putting these up here for hopefully NetSuite developers working on 2.0. If there is another place, let me know. I’ve also been providing documentation feedback as I discover issues.

This is another inconsistency. Sublists. If I add a dynamic sublist to a form on beforeload and wish to populate the list with data, the Line Numbering starts with zero (0), whereas virtually every line item “get/set/remove/select” call, the line number starts with 1. Whatever the argument for using a base index of zero or one, it should be consistent. For those methods that add lines by an array, that can still be zero based because you are not identifying any line numbers so NetSuite can just assume element zero belongs to line 1, etc.

[Author]

Posts