You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During some testing have found that 2015.1 will not coerce a StringCustomFieldRef value into an Integer field on a custom record. Before sending record to NS I update the type of the field to LongCustomFieldRef and that solves the issue. Question is how to handle, how do we infer which fields can remain string and which need to be long.
Hmm, this is a bit tricky: ruby isn't strongly typed, and I don't think it would be ruby-like to infer field type off a specific lower-level variable class. Forcing users to to something like ns_record.custom_field_list.custfield_field = the_value.to_i would be error prone.
What do you think of adding this to netsuite_rails. We could add a :long field type to the field hints mapping:
@iloveitaly I like it. I think you're right and it's fairly common that you'd see both numeric & string values that end up going to a NS string field. So using the variables class on the ruby side would prove difficult and inconsistent. Adding to the field hints would work well and be a clean update removing the need to set the field type explicitly in the NetSuiteRails :before_netsuite_push for example.
During some testing have found that 2015.1 will not coerce a StringCustomFieldRef value into an Integer field on a custom record. Before sending record to NS I update the type of the field to LongCustomFieldRef and that solves the issue. Question is how to handle, how do we infer which fields can remain string and which need to be long.
https://github.com/NetSweet/netsuite/blob/master/lib/netsuite/records/custom_field_list.rb#L107
The text was updated successfully, but these errors were encountered: