[darrenhillconsulting Contributions: 0Level 1☆]

Ladies/Gents,

Ever create a SS 2.0 script (or migrate one from SS 1.0) only to find an unsupported or non-working API call? Well, needless to say I have. One of my battles was to try and disable a sublist field.

Well, here’s a hack you can use to continue to code with SS 2.0, and ‘bridge the gap’ of those missing SS 1.0 features.

Simply, access those old SS 1.0 functions from the ‘window’ object.

Example:

window.nlapiDisableLineItemField(‘assignee’, ‘serviceitem’, true); // TODO: Come back and update once SS 2.0 is ready Notice: I ‘tagged’ this line of my code with a TODO, so that I remember to update it accordingly later.
This is a cached copy. Click here to see the original post.

This post has received 1 vote up.

[al3xicon Contributions: 0Level 1☆]

Nice, thanks darrenhillconsulting !

[MChammaTX Contributions: 0Level 1☆]

Cool thanks Darren. I’ve been shiving by importing the old 1.0 code as modules but your hack is much simpler.

[CREECE Contributions: 0Level 1☆]

Cool find! Seems like this can be yanked at any time and is probably not wise to do. Any time I see “hack” and netsuite code, I immediately see a nightmare of maintenance.

[darrenhillconsulting Contributions: 0Level 1☆]

Originally posted by CREECE

View Post

Cool find! Seems like this can be yanked at any time and is probably not wise to do. Any time I see “hack” and netsuite code, I immediately see a nightmare of maintenance.

I’ll be long dead before Netsuite yanks SS1.0. Believe me, I’m all for using API’s … but if they don’t exist (or work), one must search in dark corners.

[mattdahse Contributions: 0Level 1☆]

That is a pretty cool hack.

For what it’s worth, here’s how I approached the problem of disabling a line item field in a client script in 2.0. (the jquery library is loaded in this script)

Code:
/**
* This function attempts to disable an item sublist field through SuiteScript API, and disables the field
* through the DOM if that fails.
*
* @param rec {N/currentRecord.CurrentRecord}
* @param fieldId {String} Internal id of a column field
* @return {void}
*/
function disableSublistField(rec, fieldId) {

/* {Number} The current item index */
var line = rec.getCurrentSublistIndex({sublistId: ‘item’});

try {
/* {N/record.Field} */
var field = rec.getSublistField({sublistId: ‘item’, fieldId: fieldId, line: line});

field.isDisabled = true;

} catch (e) {

/*
* The getSublistField method will throw an error if the line has not yet been committed, so we have
* to disable the field through the DOM and let a validateField function guard it from edit.
*/
jQuery(“input[name=inpt_” + fieldId + “]”).prop(‘disabled’, true); //For select fields
jQuery(“input[name=” + fieldId + “_formattedValue]”).prop(‘disabled’, true); // For text/number fields
}
}

[darrenhillconsulting Contributions: 0Level 1☆]

Nice work mattdahse! I think I’ll use that and swap in my hack for your jQuery.

Cheers!

[agrimaldo Contributions: 0Level 1☆]

You should be able to disable a field with the “isDisabled” property like so:

Code:
var objField = objRecord.getSublistField({
sublistId: ‘item’,
fieldId: ‘item’,
line: 3
});

objField.isDisabled = true;

[andy Contributions: 0Level 1☆]

Originally posted by darrenhillconsulting

View Post

Ever create a SS 2.0 script (or migrate one from SS 1.0) only to find an unsupported or non-working API call

Every – single – time.

[Josh HidleyMember Contributions: 1Level 1☆@josh_hidley]

The new SS 2.0 method of selecting each sub-list item and then calling setCurrentSublistValue() was way too slow for us, but we needed the script to be in SS 2.0 for the new AMD packaging. Here’s a link to our solution: https://stackoverflow.com/a/46182018/2635605

[Author]

Posts