Support non-record field results in saved search responses #426
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.
iloveitaly
force-pushed
the
master
branch
2 times, most recently
from
7185ffc
to
df796ee
Compare
|
I hit a similar problem on my integration, though not via a saved search, just a basic search through the API. Searching invoices, TransactionSearchRowBasic has a field This PR seems to be a step towards making these search-only fields accessible, albeit faking them as custom fields, though I hit a few snags using it. First, if the search is returning That line likely needs to check if Secondly, this PR seems to store the field name as But for newer integrations (2013.2 and newer?), I believe custom fields should be referenced by Therefore, where I'm using 2020.2, if I try using this PR, the custom fields returned have a nil netsuite/lib/netsuite/records/custom_field_list.rb Lines 19 to 21 in 438c233 Perhaps this PR needs to conditionally set the field name to either Alternatively, I wonder if it'd be better to model the search results as proper classes where you could define the fields each has, as opposed to an approach like this. I guess it'd come down to whether you'd expect to get instances of the record (ie. Invoice) back from a search, or instances of a search result (ie. TransactionSearchRowBasic) back. The former certainly makes it easier to then push changes back to NetSuite by manipulating the returned instance. |
|
@cgunther if you can rebase this PR and fix it up to work with the conditions you mentioned, I can take a look at getting this merged. |
|
I'd agree, this is predominantly addressed by 676a618. |
Attempt to document NetSweet#483. I wasn't sure how best to convey this given it affects consuming the search results, not performing the search itself. It should also be unsurprising that you'd access these search-only fields the same way you'd access regular or read-only fields. Had we buried these search-only fields in custom fields, like NetSweet#426 first attempted, then I'd find that more surprising and warranting clearer documentation.
Attempt to document #483. I wasn't sure how best to convey this given it affects consuming the search results, not performing the search itself. It should also be unsurprising that you'd access these search-only fields the same way you'd access regular or read-only fields. Had we buried these search-only fields in custom fields, like #426 first attempted, then I'd find that more surprising and warranting clearer documentation.
Attempt to document NetSweet#483. I wasn't sure how best to convey this given it affects consuming the search results, not performing the search itself. It should also be unsurprising that you'd access these search-only fields the same way you'd access regular or read-only fields. Had we buried these search-only fields in custom fields, like NetSweet#426 first attempted, then I'd find that more surprising and warranting clearer documentation.
TL;DR -- This exposes some additional search result information that is currently being dropped
Sometimes NS makes information available within saved search results that are not record fields. For example, you can run an
InventoryItemsearch through the GUI that returns:Location Available(the quantity available at the default location)Location Reorder Point(quantity at which you should reorder at the location)Location On Order(quantity on order for the location)These aren't record fields, as you can see with a quick CTRL-f through the NS schema docs. There's no field named
locationQuantityAvailablein the schema -- even though one comes back in the XML response to the saved search:They also aren't custom Formula results either (which NS doesn't seem to expose through Suitetalk).
Nor are they custom fields. This information is just default, standard-issue NetSuite.
For that reason, I think 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.
I have a need to support them in my own projects, and think others would benefit from having access to them as well.
EDIT: tests pass for me locally
