I have a workflow action script that accepts two i...
# suitescript
j
I have a workflow action script that accepts two integer parameters. Just as an extra precaution, I also parseInt them. They represent a script ID and deployment ID. Despite this, for one user, suddenly the value keeps adding a .0 on the end. Nothing changed, it was working fine before. The only work around was to wrap it in a String. Why?
Copy code
function goToSuitelet(context) {

      	var script_id = parseInt(runtime.getCurrentScript().getParameter('custscript_go_to_suitelet_script_id'));
      	var deployment_id = parseInt(runtime.getCurrentScript().getParameter('custscript_go_to_suitelet_deployment_id'));
    	var deployment_id = 1;
    	var params = {txid: context.newRecord.id};

    	redirect.toSuitelet({scriptId: script_id, deploymentId: deployment_id, parameters: params});

	}
I had to change the last line to
Copy code
redirect.toSuitelet({scriptId: String(script_id), deploymentId: String(deployment_id), parameters: params});
The error:
Copy code
Account: xxxxxx
Environment: Production
Date & Time: 01/19/2023 02:27 pm
Execution Time: 0.00s
Script Usage: 0
Script: Go To Suitelet
Type: Workflow Action
Function: onAction
Error: INVALID_ID
You have provided an invalid script id or internal id: 3312.0
logged out the incoming value, it’s definitely just 3312
n
I think your issue is it's trying to use "3312.0" and not "3312"
d
I would pass customscript_xxx and customdeploy_xxxx as the script and deployment id, instead of using the number internal id Because number internal id might be different between sandbox and prod, but you can control the "name" internal id
r
Have you tried removing
parseInt()
?
j
parseInt actually isn’t doing anything, as far as I can see (I logged out the value before and after the parseInt and neither had the .0), the .0 literally seems to be being added at the time that the argument is passed to the redirect. I’ve encountered this weird behaviour before. What’s ultra weird is that it’s not happening for everyone
r
Ya, I believe I've seen that issue before. I can't remember how it was resolved.
j
I think they only workaround is to wrap my (INTEGER!!!!) value in
String()
which forces it to be
"3312"
instead of just
3312
.
Which is super backwards in my brain
it’s like NS needs it to be a string, so it converts it for you (helpful!) but in doing so, adds a .0 so you end up with
"3312.0"
for no good reason
but if you pre-String it, it’s like “my work here is done” and leaves it alone
it’s effed up
r
Well, whatever's clever 😂
j
the other place I’ve encountered this is returning a parameter of type List/Record and you are returning the internal id as an integer. NS will string it and you end up with 123.0 instead of just 123
I hate ns sometimes
Actual example from our code:
message has been deleted