https://netsuiteprofessionals.com logo
Join Slack
Powered by
I'm trying to access a field, and I only get an er...
# suitescript
r
I'm trying to access a field, and I only get an error for invalid search operator on XEDIT (afterSubmit on Case). It appears that 
context.newRecord.getValue('company')
doesn't populate on XEDIT, but does on EDIT. Any idea what's happening here?
b
its ss1, but same concept applies
r
So XEDIT only returns fields that are changed? That's a problem.
b
r
Copy code
oldStatus === CLOSED ||
assignmentQueue !== IT ||
surveySent === true ||
caseStatus !== CLOSED ||
!teamMemberIsEmployee ||
!assignedTo ||
caseType === MONITORING_ALERT ||
reasonClosed === DUPLICATE ||
reasonClosed === NO_RESPONSE ||
reasonClosed === WITHDRAWN
I need all of this data. I had been using newRecord primarily with EDIT. So any of these fields could be present on newRecord, and any of them could also not be present...
e
If you need fields that weren't changed, you have to load the record or use a lookup
b
use the old record
it has the current values (if they arent in the new record)
e
ah yes, the old record will also have the values that were not changed
r
so get everything returned from newRecord and then get everything else from oldRecord. got it. thanks
b
unless you are guaranteed nobody can unset fields
you need to check Record.getFields() to see if you should use the new record or old record
c
load the record and just call it a day
r
wouldn't a search be faster?
c
Depends on the wind that day
r
we have 19 workflows on case. lol
c
Could be good or bad there depending on what they do.. but at 19 i'd say there's PROBABLY going to be some redundancy and maintainability issue.
r
yes, that's correct. there's one that runs onFieldEdit, and shouldn't...
s
If you are going to just load the record then why not just use oldRecord?
r
What I want to use is just the newCase fields, changed or not. Because of the XEDIT context, the newCase fields I used in EDIT are not available.
c
He needs other values.. they may or may not have changed.. if you load the record, you're at least guaranteed to have the latest data.
b
unless something wierd is happening, the old record will be the same as the loaded record
s
Yeah that's what I mean, why load it if it's already there
c
there's scenarios where the data isn't on it yet
e
The loaded record would not be the same as the old record in an 
afterSubmit
I didn't catch which event type this was
c
like you think its on there but if you do a lookup it doesn't exist
r
currently the context for my script is both EDIT and XEDIT. i didn't understand the difference with newRecord, so the script fails in XEDIT.
i could separate them, or not
record.load or a search/lookup would mean not having to create different procedures for EDIT and XEDIT...
do you all have a single procedure you use for both EDIT and XEDIT? or do you handle them separately?
c
I usually just load the record in xedit since it only sends in what changed
you avoid any issues at that point IMO
e
My typical approach, regardless of script type or event, is to distill the NS data objects (
Record
, 
Result
, etc) down into plain `Object`s first, then my business logic operates on native Objects instead.
so EDIT might read all its data from 
newRecord
, while 
XEDIT
reads all its data from a loaded 
Record
, but either way the data is transformed into an 
Object
that the business logic function accepts
c
^ I do the same
s
I also generally do explicitly handle XEDIT and EDIT differently.
r
I used search.lookupFields.
Open in Slack
PreviousNext
Powered by