https://netsuiteprofessionals.com logo
Join Slack
Powered by
n
message has been deleted
a
doesn't appear to be anything wrong with your code here... other than doing your record.save() inside your debug which is just gross šŸ˜‚ I'd be curious where 
lineId
and 
itemDate
and 
item
are coming from. is it possible you're getting a value in there from an iterator which is off by one or something?
n
message has been deleted
I have a saved search and this is the row its bugging on
I just have the log.debug portion for testing purposes, it wont be in production version
its funny yes, but it helps me keep track of where in the code things are executing
a
i'd just log all your variables before you do the setSublistValue
n
item = item id from the SS, itemDate is a dictionary of all items atp time + the current date
Copy code
var itemDate = {};

        // Sets the ATP lead time inside the itemDate object
        function setItemAtpLeadTime(days, item) {
            var date = new Date();
            date.setDate(date.getDate() + parseInt(days));
            itemDate[item] = date;
        }
a
is there some NS goofyness around item/expense sublist where they're a combined list in view mode but separate sublists in edit mode? might not be on SOs, and might only be in client context or something, but I remember that being an issue at some point
n
im not sure on anything in that regard, the previous lines all ahve similar values but run fine. its just this record
a
this code runs against other lines on the same sales order and its running ok?
n
message has been deleted
yes
all run down the same if/else logic
a
that set lead time function has a days variable being passed in... anyway that could be passing in as 
null
or something else it can't use?
n
the days is the atp location time
in the SS its 365
message has been deleted
message has been deleted
have this configured to only work with valid atps as well, so the itemDate only exists if the atp exists
a
yeah, idk this is a weird one. I'd just add some more logs right before the setSublistValue call
and log the values of itemDate[item] and lineId
if they look fine.... then it's not your code and just something else weird with .. the item, the SO or something
n
true, ill get those in and run a test
perpetual pending status on running the script hahaha hope this doesnt take too long
e
SS2 or SS2.1?
n
2
e
I thought maybe you were getting the NS issue where it returns ints as floats, but I don't recall seeing that in 2.0
n
these r logs
@Anthony OConnor, could it be that the line ID isnt what I need to pass in as the line number?
got it, i think I need the line sequence number and not the line id
Its working!!
šŸ‘ 1
Now we have a new one haha ":"Please choose an item to add
b
that suggests that you did not take into account that line index starts at 0
and that the failing order has an item on the last line
n
ohh lets go battk
b
the other successful ones werent actually successful, you updated the wrong line
šŸ˜ 1
n
you are the best debugger
good thing its a sandbox environment meant only for testing this šŸ˜„
Battk always comes in clutch in the times of need
lets go! it went past that breakpoint
s
this is rather fragile coding style overall, but I will disagree with Anthony and say the specific bit about logging your record.save() in a log statement isn't gross to me.
a
really? he's not just logging it, he's executing a record save, on a line that starts with log.debug that's horrible for readability
s
not in my opinion it's not. It's concise, avoids declaring extra variables, and avoids that line printing if an error happens.
I'm not sure how it could be more readable in fact - a few, clear characters on a single line?
my only issue with it would be to suggest a higher level of log severity - perhaps AUDIT
assuming that saving that record and logging the id is pretty useful to have logged (if the intent is not just a debugging thing)
a
when I'm looking at code for the first time and trying to understand what it does, there's a good chance I'll ignore any lines that start with log.x because generally lines that start with log.x dont DO anything I'm going to care about.
s
I do see your point, especially if you have code littered with log statements (we use AOP for most logging, so log calls are usually quite intentional and not littered about)
I can't speak for @Nbtwistā€™s motivations of course šŸ™‚
a
I mean if it was a common practice, it wouldn't be an issue, but I've literally never seen that before, so even though the code is perfectly fine its unconventional, and I'd absolutely tell a junior that in code review.
n
All of this is in a sandbox environment just to get through testing the functionality of the script! I clean up those iterations before production haha
s
SuiteScript is far from conventional/idiomatic JS in general
a
yeah I have no issue with it at all during development šŸ™‚
whatever works for you šŸ™‚
n
message has been deleted
it does give me nice little logs like this to keep track of which record is being processed
The script also runs into a good bit of limitations so I have a rescheduling process in place to pick up where it left off and saving the important data to a file in the file cabinet which gets loaded anytime the iteration # is more than 0
a
yeah what you're doing is very standard, but it would generally be written as
Copy code
let recId = rec.save();
log.debug('record saved', recId);
s
at least use 
const
if you insist on doing that temp variable šŸ™‚
n
why const over let?
a
cos it doesn't get changed so its more correct
I'd usually just use var though, but I've gotten used to working with a linter that yells at me if use vars šŸ™‚
šŸ˜‚ 1
s
we use 
const
for everything - except when we can't
that way, any 
let
in the code stands out as a special case, and we know something interesting is happening because mutation is involved
a
... that's probably a better practice šŸ‘
n
Ye im wrapping things around try/catch with better error handling now. I usually like to just determine all the potential errors upfront
s
this has waded off into different territory, but FWIW, we don't do blanket try/catch blocks either - too often results in exceptions being silently swallowed
šŸ˜‚ 1
it's alarming how many times I've seen people just cover up bugs/errors with 
try { ...buggy code } catch {}
n
Yea the code isnt super buggy in this instance. It loads a record, and updates the corresponding line. The only errors I have received since fixing things are errors with saving the record because of missing data on the sales order, which isnt a script issue but an SO issue
I want to make sure it can process all the records needed, so the try catch will allow it to continue
a
haha really Shawn? like on purpose? I've seen try blocks that swallow errors they shouldnt, but I never thought it was was designed that way... guess I just apply Hanlon's razor to those instances
Never attribute to malice that which can be adequately explained by stupidity
s
I can't say if it was on purpose or not - only reporting what I've seen - generally it's code I'm reviewing by an unknown author (or unvailable anyway).
2 Views
Open in Slack
PreviousNext
Powered by