Creating custom pop-ups can be super helpful when implemented correctly. Our previous blog will help give you some ideas for your own use cases. Today we will walk you through creating your own. Having covered some of the foundational script types in SuiteScripting, we want to delve into some of the unique possibilities these components give us. The message module allows us to show a message to the user in an unobtrusive way. Sometimes, however, we need the user’s undivided attention to address a particular concern. This is where the N/ui/dialog module can come in handy.

Creating a Basic Pop-up: dialog.alert

In a Client Script deployed to a certain record (e.g., Sales Order, Inventory Item, Customer Record), we want an entry point that will trigger our new pop-up. For instance, we could choose to activate our pop-up as soon as the page is loaded (pageInit). Also, don’t forget to define the ‘N/ui/dialog’ module at the top of your script! Here’s our basic structure:

//Add additional code
   ...
function pageInit(context) {
    var currentRecord = context.currentRecord;

    function success(result) { console.log('Success with value: ' + result) }
    function failure(reason) { console.log('Failure: ' + reason) }

    dialog.alert({
        title: 'Hello World!',
        message: 'Click OK to continue.'
    }).then(success).catch(failure);
}
    ...
//Add additional code

These pop-ups of course can be shown at more helpful times in your Client Script. For example, before saving a record (saveRecord() function), an automation could occur to validate the data entered. If the data does not meet a certain criteria, a pop-up could notify the user. The dialog module does have certain complications when attempting to prevent a record from saving however. Be sure to read our final paragraph where we provide a solution to a known complex issue.

Other Pop-up Possibilities

There are two other variants of the dialog module: dialog.confirm and dialog.create.

Dialog.confirm simply provides a ‘cancel’ button alongside the ‘ok’ button. This allows the user to either proceed with or cancel their action. If ‘ok’ is clicked by the user, result in the success() function will have a value of true. If ‘cancel’ is selected, result will have a value of false. Result can then be manipulated to perform certain functions. For example:

function success(result) { 
    if (result == true) {
        console.log("OK has been selected");
        //More code here
    } else if (result == false) {
        console.log("CANCEL has been selected");
        //More code here
    }
}

Dialog.create is the most flexible of the three types. It allows us to specify how many buttons we have, what they will be called, and what they will return when they are clicked. For example:

var options = {
    title: 'Which OS will you choose?',
    message: 'Click a button to continue.',
    buttons: [
        { label: 'MacOS', value: 1 },
        { label: 'Windows', value: 2 },
        { label: 'Linux', value: 3 }
    ]
};

function success(result) { 
    if (result == 1) {
        console.log("Thank you. You may proceed.");
    } else if (result == 2) {
        console.log("This is not acceptable.");
    } else {
        console.log("Please try again.");
    }
}
function failure(reason) { console.log('Failure: ' + reason) }

dialog.create(options).then(success).catch(failure);

Other Pop-up Personalities

Tasting the freedom that dialog.create can provide, we can actually take the dialog module a step further. The dialog module can actually support custom HTML and CSS. Although this customization is not always necessary, it can provide a helpful way to prioritize or organize information. We put our custom HTML/CSS in the message key of the options object.

var options = {
    title: 'CHOOSE YOUR SIDE:',
    message: '<div style="color:green;"><b>Which OS will you choose?</b></div><br><br> \
    <div style="color:red; background-color:black; padding:10px; border-radius:10px;"><b>• MacOS<br>• Windows<br>• Linux</b></div>',
    buttons: [
        { label: 'MacOS', value: 1 },
        { label: 'Windows', value: 2 },
        { label: 'Linux', value: 3 }
    ]
};

Potential Roadblocks

As mentioned previously, there is a common problem when trying to use a dialog.confirm or dialog.create on in a saveRecord() function. In a saveRecord() function, returning true will cause the record to save, while returning false will prevent the record from saving. The issue lies in the nature of the dialog module. It’s greatest strength is also its Achilles’ heel. The call, dialog.create() returns what is called a Promise, which is an asynchronous assignment. This means that if you were to assign a variable to it (e.g., var choice = dialog.create(options)...), the variable (“choice”) would be assigned to the Promise skeleton. It never receives the value of the user’s selection. Therefore, there is no way to cause a record to save from a button on a pop-up, at least not officially. There are two possible work-arounds however.

First, sometimes the record doesn’t technically need to be saved. For example, in a Suitelet, we can work around this problem by manipulating the page in other ways. We could for instance reload the page, pass certain parameters into the URL, and check whether there are URL parameters at the beginning of the Suitelet. Thinking outside the box is key to making this work.

Another (unoffical) option is to manually make the record save. This essentially is telling NetSuite that you have clicked the UI button called “SAVE” on the record. We can do this by writing getNLMultiButtonByName('multibutton_submitter').onMainButtonClick(this); return false;. Be sure to include the return false; statement, as it is also necessary.

function success(result) {
    console.log(result + ' has been clicked.')
    if (result == true) {
        getNLMultiButtonByName('multibutton_submitter').onMainButtonClick(this);
        return false;
    }
}

When investigating the “SAVE” button through the browser inspector, we can see this native NetSuite function call.

We hope you have found this post helpful. Keep up to date on our latest SuiteScript tutorials by signing up to our email list!

3 Reasons You Should Switch from SuiteScript 1.0 to 2.0

There are many reasons to consider switching from SuiteScript 1.0 to 2.0. 3 reasons are modularity and compatibility with JavaScript and NetSuite’s APIs.

SuiteScript 2.0 User Event Script After Submit

In this blog we touch briefly on the 3rd and final User Event function that is available: the After Submit function. With this basic foundation of the structure and capabilities of each function, we will be ready to dive into some real life examples in the next...

SuiteScript 2.0 User Event Script Before Submit

In the last tutorial we looked at the setup of the Before Load trigger for User Event scripts. In this tutorial will introduce the basic setup of the 2nd of 3 main User Event triggers: the Before Submit trigger. I want to spend some time looking at each of these...

SuiteScript 2.0 User Event Script Before Load

User Event Scripts are one of the most common script types to work with. In the next several blogs I will walk through some example User Event scripts, and this first blog will introduce the basic setup of the Before Load trigger in a User Event script. Before Load...

Client Scripts Vs. User Event Scripts

Many of the tutorials in this series have been about the Client Script. If you have been following along, you should understand how to create and use client scripts in different basic scenarios. Now we can start touching on the basics of User Event scripts. When we...
0
Would love your thoughts, please comment.x
()
x