This site was built to compliment the existing NetSuite Professionals Slack Community by adding a means for members to easily find answers to common questions and to create a searchable database of those questions and answers.

NetSuite Professionals

NS support:
&gt; Our engineers have confirmed that the Recurring Billing RESTlet triggers the Client Scripts because RB processing requires certain processes from Client Scripts that are deployed to Sales Orders

NetSuite has somehow designed their Restlet to trigger client scripts, however it triggers ALL client scripts deployed on Sales Orders, not just the ones from their bundle.  They are suggesting that the creators of other bundles should put logic in their code to not run when triggered by the RB restlet.

Yes.  The worst part is that NetSuite is acting as if this is a perfectly normal and reasonable thing to do.

I'm curious. What would you expect to happen here?

The normal behavior is no client script execution since the RESTlet is server side.  This is what happens for other server side scripts.  At a minimum, it should only trigger client scripts related to the RB bundle and not all client scripts.

I also would expect no client scripts to execute, or as <@U38PGCNGN> said, only triggering the RB bundles client scripts.  Triggering all of the client scripts seems to be unnecessary and in this case, it causes an error that can't be reproduced through the UI or in any other script we have that creates sales orders.  I am still not sure how they are even being triggered.

It's reasonable to expect no client scripts to execute on the server.

In fact, for the suiteanswers / manual page "What is Client SuiteScript?" (10645) the first sentence is
&gt;Client scripts are SuiteScripts executed in the browser.

:100: I ran into a similar issue with a client script on an address form being triggered server side. I had to add in `if(! window) { return; }` to fix

Thanks for the tip <@U29QCJQF3> .  I'll pass that suggestion along to the third party bundle creator when I get them on the phone today.  I think it's a bit unreasonable to ask every third party to workaround this issue, though.  When I write a client script, my expectation is that it runs in a browser only.  What/who is interacting with the page in a server-side client script execution?

In the future, I guess we will have to consider non-human users when we write client code and interfaces.  Software interacting with software.

That's definitely a reasonable expectation. Speaking of which <https://www.facebook.com/nixcraft/photos/so-this-just-happened-a-bot-found-a-vulnerability-in-a-dependency-a-bot-sent-a-p/2913953455284680/> :laughing:

I believe there's an easier solution than code changes to solve this:

There's now a "Context Filtering" menu in Script Deployments so you can make sure your client script only runs in Client.

<@UAA1TMMTR> is that a 2019.2 feature?  We aren't being upgraded until mid-October.  I see the Context Filtering menu in Release Preview, but not in our sandboxes or production.

Okay, we'll have to wait a little while to utilize this solution then, unless we can find some other way around it in the meantime.