I’m using `search.lookupFields()` to return the se...
# suitescript
j
I’m using
search.lookupFields()
to return the selected values for a few multiselects which are custom Entity Fields. I’m noticing that some of these multiselects return as an object with two properties,
text
and
value
where each is a comma-separated list of the expected values, and some of the other multiselects are returning as an object with one property per selected value, indexed 0, 1, 2, 3. What’s going on here?
a
when you say custom Entity fields, you mean the fields themselves are on the entity record and are
custentity_
? not that the record type of the List/Record is set to Entity?
if its the former, then I'd suggest looking at the list/record type and see if there's a pattern there as to which types return with the text/value and which return with just a index and value
j
yes the fields themselves are on the entity record and are custentity_
All are Multiselect of various types of custom records
oh wait
maybe some are lists
nope all custom record
a
okay, do all the custom records have include name field checked? cos if they don't they can't very well have a name (text) property 😉
j
some do, some don’t, I don’t actually need the name though. I’m just trying to have a common way to retrieve the ids of the selected values in each multiselect without doing a record.load or suiteql.
my question was more if anyone had encountered this inconsistency before.
(search.lookupFields returning different types of objects when all are multiselects of custom records)
a
not specifically but cant you just check for a text property and use that, and then add a conditional that if you're not getting a text property to use the value from the index?
j
I already have a workaround. It’s just …. WEIRD that it does this.
a
LOL okay, NS is sometimes weird, and you have to workarounds sometimes, I've not specfically encountered this one before though. is it possible you're doing some kind of sourcing/filtering/validation on the fields themselves, and that's what is making them differrent?
j
I don’t think so. And even if so, search.lookupFields should work the same way
a
oh youre talking about the response FROM search.lookupFields, I thought this was trying to get the value to use IN search.lookupFields
j
response, yeah
a
oh well then that's going to depend on which fields you're looking up from the custom record then.
j
sorry I can’t really get a screenshot without blurring a bunch of stuff out
no no I’m doing a search.lookup({type: record.Type.VENDOR, id: whatever, columns: [‘custentity_whatever1’, ‘custentity_whatever2’]});
a
oh okay, so I was understanding orginally 😄
yeah so I would expect those to come back as id/text pairs cos they're referencing actual records. with names and ids, i guess with exception if names aren't included on the custom record
j
both custentity_whatever1 and custentity_whatever2 are multiselects of custom records
a
which... is weird cos if you're showing these in a multselect i think you need the names so they make sense to people?
j
some are autonumbered
a
hmm is it different if you've only got 1 option selected vs. multiple?
I agree its odd that they would make this inconsistent
j
but whatever1 comes back as
Copy code
{
	text: "thing, nextthing, thirdthing"
	value: "4, 17, 21"
}
and whatever2 comes back as
Copy code
{

	0: {value: '3', text: 'Stuff'},
	1: {value: '6', text: 'More Stuff'},
	2: {value: '7', text: 'Even More Stuff'}

}
a
ooh that's totally crazy i thought you meant one version just didn't have text values, and they were coming back as
Copy code
{
    [
         {value: '2', text: 'Thing'},
         {value: '5', text: 'Other Thing'}
    ]
}
and
Copy code
{
    [2, 5]
}