Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I've built some custom CA's for Ubercart that allow me to access user profile fields for tax calculations and the contrib uc_discount module, but to my surprise discovered that the only code that actually passes the order's UID to the checkout page is the optional shipping quote pane as a hidden form field. In digging, I found that the JavaScript code from the core uc_payment module is where the serializeOrder call is defined that compiles the order information from the form to send back to Drupal for the tax and uc_discount contrib AJAX calls. This piece of code always stuffs the order's UID value with 0, which being the guest user, prevents me from pulling the user information in my custom CA's to calculate taxes and discounts.
The attached patch was made against the following release of UC 2.x-dev to add the UID associated with the order in checkout to the serialized checkout form info passed into these AJAX callbacks:
; Information added by drupal.org packaging script on 2011-02-25
version = "6.x-2.x-dev"
core = "6.x"
project = "ubercart"
datestamp = "1298620468"
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1132378-uc_payment-checkout-uid.patch | 1.93 KB | longwave |
| ubercart-2.x-dev-checkout_order_uid.patch | 1.19 KB | arpieb | |
Comments
Comment #1
longwaveCan't you just use global $user and check $user->uid in your custom CA?
Comment #2
arpieb CreditAttribution: arpieb commentedNot really - the CA doesn't know the context of the order (is it being created/edited by the actual customer, or a site admin?) so global $user is not a valid option, and the CA ultimately only has the order object to work from. Additionally, many other modules have logic that is pinned to $order->uid, and when this is 0 the guest user logic kicks in, which is not always the desired behavior if you're invoking hooks or calling other public methods under the hood.
Yeah, you could hack around the problem with module code, but ultimately it's a core issue with UC. Even the core shipping quote module passes the order's UID to the checkout form pane and back via AJAX calls from uc_quote.js:quoteCallback() because it needs it to accurately process core CA's related to shipping:
Since all checkout panes are optional via the store admin, one cannot code modules on the assumption that the quote pane's form item is always going to be available either.
Comment #3
arpieb CreditAttribution: arpieb commentedOK, testing your suggestion it works for the checkout use case - but what about the case where a store admin is editing an order? Current logged-in user information isn't
validcorrect at that point for a CA - but the order's UID is.The only context the CA's have is the arguments passed to them, so the checkout page needs to stay consistent with the rest of the system regarding what it passes back to be processed by the CA hooks, right?
Comment #4
TR CreditAttribution: TR commentedComment #5
longwaveThe attached patch moves the hidden uid from uc_quote to uc_cart so it is always available, and then sends that value instead of 0 in the Ajax callback.
Comment #6
longwaveCommitted #5.