Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix "undefined method `[]' for #<Nori::StringIOFile>" when adding File
When calling `File#add`, the response XML sets a `type="file"` attribute on the `baseRef` element, where "file" corresponds to the NetSuite record. This then causes Nori (the XML parser used by Savon, the SOAP client) to interpret that element as representing a base64 encoded file, so it tries to get fancy about how it parses that element into a hash by returning an instance of it's `StringIOFile` class: https://github.com/savonrb/nori/blob/f59f8e18b0e53285c87d75a635058745e66b0bfb/lib/nori/xml_utility_node.rb#L131-L136 Either NetSuite's doing something non-standard with it's use of the `type` attribute that Nori is trying to enforce, or Nori is over-aggressive in trying to typecast to aid the developer. The end result was that when we tried to extract the `internal_id` from the response, the `body` was actually an instance of `StringIOFile`, not a hash: https://github.com/NetSweet/netsuite/blob/f0e46a076d0e7cb2abd5e9001ccbfd4bbb3d35c3/lib/netsuite/actions/add.rb#L80 To work around this, as I don't see a way to disable such behavior in Savon/Nori, if we detect the `baseRef` element was parsed to `StringIOFile`, we'll then take the raw XML and parse out the `baseRef` ourselves, returning a hash with the `internal_id` as we'd exect from non-`File` responses. I'm not thrilled with this solution. If we ever needed something else from the `baseRef` element, this effectively drops all other attributes for file records. It also introduces explicit references to `Nori` and `Nokogiri`, both of which are dependencies of Savon, but I'm not sure if that means this gem should list them as explicit dependencies to guard against Savon replacing them in a future update. Listing them as dependencies would then require keeping their version constraints in sync with Savon most likely. I believe this answers a question from #481: #481 (comment) However the fix in #481 solves it by not trying to extract the `internal_id`, which would create a problem if someone wanted to add a file then save the ID in their own database for future use.
- Loading branch information