After an upgrade to UC 3.4, a client's site consistently rejected UPS shipments at the review step with the following message:

Hard Error 120307: Missing/Invalid ShipFrom/Address/PostalCode.

The error occurred in uc_ups_fulfill_order_validate() inside uc_ups.ship.inc. It appears that the structure of the form_state passed to the function has changed from what it expects. I'm not sure whether this was the best place to address the problem, but given the "total hack" comment already present, it seemed reasonable to simply adjust its expectations for now. Patch to follow momentarily.

CommentFileSizeAuthor
#1 ups_shipfrom_error-1930528-1.patch2.15 KBjerry

Comments

jerry’s picture

jerry commented
Status: Active » Needs review
StatusFileSize
new ups_shipfrom_error-1930528-1.patch2.15 KB

Patch for the issue described above.

tr’s picture

tr commented

Looks like the form structure was changed by #1844402: AJAX crash and address load/save failure in uc_shipping_shipment_edit() form. Specifically, $form['origin']['pickup_address'][#tree] =TRUE was added in that patch.

Please test to see if your proposed fix breaks the problem raised in that other issue.

Note this issue will also affect all other shipping fulfillment modules. uc_fedex is the only other one I know of, and that's mine so I will take care of fixing uc_fedex when we get this issue resolved for uc_ups.

jerry’s picture

jerry commented

Patched version still passes the tests provided in #1844402: AJAX crash and address load/save failure in uc_shipping_shipment_edit() form.

tr’s picture

tr commented

Excellent. Hopefully DanZ can test the patch in #1, since I know he's using this feature of uc_ups.

DanZ’s picture

DanZ commented

I'm not using UPS, sorry.

Instead, I am using a heavily-altered version of uc_shipping_shipment_edit() in https://drupal.org/project/uc_stamps (which makes three fulfillment modules). Because it uses an _alter(), it automatically accounts for the changes in #1844402: AJAX crash and address load/save failure in uc_shipping_shipment_edit() form.

The UPS module doesn't do an _alter(). Instead, it has a modified copy-paste of that form. So, that form must be updated, per the patch. (Avoiding this problem is why I went with the _alter(), although that technique has its own awkward issues.)

So, yeah, that just leaves FedEx.

Since we have another shipping coder here.... As I've mentioned before, I dislike the entire UI structure for shipping, and hope to see it replaced. I'd like to see a common interface for all shipping methods, with an easy way to add customization for any particular method added by a module. I'll be working on automation first, though (creating packages and shipments without all those clicks).

sibro’s picture

sibro commented

Applied patch in #1

Now get

Hard Error 120801: Address Validation Error on Shipper address

The address looks fine.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

120801 means "address validation detects an invalid city, state, postal code combination on the shipper’s address", are you sure the city, state and postal code all match?

sibro’s picture

sibro commented

Yes, it is very clear New York NY 10115

jerry’s picture

jerry commented

Confirming that this problem still exists in 7.x-3.5, and that the patch in #1 still applies as-is and resolves the error.

If anyone else has successfully used this patch, please RTBC it so that we can get it committed prior to the next release.

jpdaut’s picture

jpdaut commented

Patch #1 fixed the problem for me. Thanks.

Drupal 7.24
Ubercart 7.x-3.5

jerry’s picture

jerry commented

Confirming that this problem still exists in 7.x-3.6, and that the patch in #1 still applies as-is and resolves the error.

Still hoping to get this into an Ubercart release. jpdaut, please consider marking it RTBC.

jerry’s picture

jerry commented
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Confirming that this problem still exists in 7.x-3.8, and that the patch in #1 still applies as-is and resolves the error.

Marking RTBC based on two favorable results and no relevant unfavorable ones. It would be great to get this committed.

jerry’s picture

jerry commented
Component: Shipping » Code

Confirming that this problem still exists in 7.x-3.11, and that the patch in #1 still applies as-is and resolves the error.

Still hoping that the patch can be committed.