Support non-record field results in saved search responses - Revised #470
Conversation
The "records" in the search group are hashes with "keys" that are the
attribute names and "values" that the data returned by the search for
those attributes (not necessarily the attribute values, though). For
example, you'll often see things like this:
```
{
:department=>{
:search_value=>{:@internal_id=>"113"},
:custom_label=>"Business Unit"
}
}
```
I think using `attr_name` and `search_result` instead of `k` and `v`,
respectively, makes it clearer what the parts of this data constitute.
Sometimes NS makes information available within saved search results that are not record fields. For example, you can run an InventoryItem search through the GUI that returns: * `Location Available` (the quantity available at the default location) * `Location Reorder Point` (quantity at which you should reorder) * `Location On Order` (quantity on order for the location) These are not record fields, as you can see with a quick CTRL-f through the NS schema docs: http://www.netsuite.com/help/helpcenter/en_US/srbrowser/Browser2018_2/schema/record/inventoryitem.html They aren't custom formula results either (which NS doesn't seem to expose through the API). And they also aren't _custom fields_. This information is just default, standard-issue NetSuite. It's perfectly reasonable to have a search that returns them as results, and thus also reasonable to expect to be able to access them through the API.
…m search results after supporting non-record fields Since these aren't "fields" (they're plain ruby attributes), they were treated as non-standard fields and populated as custom fields.
…treating non-standard search result fields as custom fields
|
@cgunther Thanks for the work here! This is definitely something I'd like to merge in. I'll need to test this against some larger projects with test suites that would give me more confidence in this change. I'm not sure I like stuffing non-custom field values in the customFieldList. Curious your thoughts on adding those as
Yes, I'd opt for this approach. |
|
I had similar concerns about hijacking custom fields, but figured I'd leverage @davidlaprade's work first. While conceptually I'd agree these are read-only fields, I'm hesitant to hijack that concept as well as I feel there's a clear difference between the read-only fields on an actual record vs these search-only fields that are really more specific to the type of search you're doing (technically I'll take a stab as reworking this towards a new field type. Longer-term it may be wise to encapsulate these search-only fields in modules mirroring the NetSuite searches (ie. |
|
Superseded by #483. |
This is a continuation of #426, addressing some snags I had using it to address a similar problem (#426 (comment)). Thanks @davidlaprade for the great starting point.
internal_idandexternal_idare now extracted from the search result to the record.For API versions 2013.2 and newer, the non-standard fields returned in search are added as custom fields on the record, using the field name as
script_id.In wrapping this up, I'm noticing that both the real custom fields and the non-standard search result fields wrap their value in a
searchValueelement, however typically for custom fields, it seems to be wrapped in avalueelement, which the record then defines a helper method to access:netsuite/lib/netsuite/records/custom_field.rb
Lines 17 to 19 in 438c233
As this PR stands now, you'd access a non-standard search result field (or custom field) via:
my_record.custom_field_list.my_custom_field.attributes.fetch(:search_value). However, after a typicalgetaction, you'd access the same custom field viamy_record.custom_field_list.my_custom_field.value. This doesn't appear to be a regression due to this PR, just an existing issue that may be surfacing now. When dealing with search results, would it make sense to copy the:search_valueattribute to:valueto ease using the same#valuehelper?I'm still new to NetSuite so I'm not sure if I'm overlooking something here.