Active
Project:
ECO (Extra Customization Options for Ubercart)
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
27 Jul 2010 at 07:04 UTC
Updated:
18 Nov 2010 at 08:32 UTC
Adding D.O. issue queue reference to Ubercart.org thread: http://www.ubercart.org/forum/ideas_and_suggestions/17206
Comments
Comment #1
WebNewCastle commentedCorrected reference thread: http://www.ubercart.org/node/17206
Comment #2
WebNewCastle commentedPrevious commits corrected errors with CVS branching/tagging. The issue with an interruption in order confirmation emails should be corrected with http://drupal.org/cvs?commit=398226.
This is currently for the development release and pertains specifically to allowing anonymous checkout (Ubercart) without backend Drupal account creation. If there are no additional issues, this feature will be included in the next release.
Comment #3
WebNewCastle commentedThis was addressed and added to the beta 2 release. I haven't had any additional reports for several weeks, so I'm marking this as fixed. If anyone experiences any issues with the specific feature, please feel free to create a new issue.
Comment #5
cybermache commentedI'm working with ECO 6.x-1.0-beta2 and drupal accounts are still being created. would you advise installing the dev version instead? From this feed it seems that the patch had been applied to the beta2 version. I followed the steps to turn off the drupal account creation and all of the options mentioned to do so are available it just doesn't seem to work. I am not getting any errors in the drupal logs either.
any help would be great
thanks
Chris
Comment #6
cybermache commentedOops didn't change the status of this forum.
I think because I still have accounts being created that this issue still exists.
Comment #7
WebNewCastle commentedSorry, I didn't see this. Hmm ... no, I don't remember any of the code changes since beta2 being related to this feature, so I don't think this the dev version would make a difference. Although you can certainly try it. Is this still an issue?
Comment #8
cybermache commented@WebNewCastle, unfortunately yes, it is still an issue for us.
We are currently using ECO 6.x-1.x-dev (2010-Aug-01) and during our last product purchase test using Google Checkout, a Drupal account was created. I am not seeing any errors that would suggest that a function involved with this feature is not completing. It just simply seems like it's not doing what it's suppose to be doing.
If there are things I should be looking for or specific information that would be helpful in solving this issue, please let me know and I'll see about adding it here.
Our Ubercart modules are as follows
Ubercart 6.x-2.x-dev (2010-Sep-17)
Ubercart Terms of Service 6.x-1.x-dev (2010-Jul-17)
UC Add to Cart Tweaks 6.x-1.0-rc1
UC Restrict Qty 6.x-1.1
In case it's possible that one of these might be hindering the ECO's functions.
Thanks
Comment #9
WebNewCastle commentedOh, ok. It's been a while since I've touched Google Checkout since I haven't gotten any requests for eCommerce development with it. But, if I remember correctly, Google Checkout "by-passes" / doesn't use the regular Ubercart checkout. Is that correct or has it changed? My recollection is that the Google Checkout button appears on the cart page /cart and "takes it from there" and using it doesn't result in going to the regular Ubercart checkout page /cart/checkout.
If that is still the case, then yes, it makes sense that it's not working. Because the module gets involved during the regular Ubercart checkout process - so it's functions wouldn't get called until that stage.
If you can confirm the above about Google Checkout, maybe I can schedule some time to look at that a little closer to see if this module can be extended to cover that scenario.
Comment #10
cybermache commentedI think that makes sense, once in the ubercart 'cart' you have the 'pay with Google Checkout' button that takes you away from Ubercart. Once you've completed that transaction google_checkout pings Ubercart with the payment confirmation. As far as I understand it. So maybe if the module gets involved after payment confirmation it would solve this issue?
Thanks for your help, let me know if I can provide more information or testing time.
Comment #11
brightboldI am also using ECO with Google Checkout, if you need additional testers on any Google Checkout issues. GC does work the way you describe - it bypasses the Ubercart checkout so you get different results from people who use Google checkout vs. people who choose other checkout methods (if you offer them).
(I would actually like for the GC folks to have Drupal accounts created, but they're not. Can we trade problems, @christophoffman? Haha.)But I didn't post to get that problem solved, just to say I can help test ECO/Google Checkout integration if you need it.Edit: account creating problem solved - that was due to a GC integration issue unrelated to ECO.
Comment #12
cybermache commented@WebNewCastle, I was looking around in ECO to see if I could tackle this one myself and I came across this function.
/uc_eco/uc_eco_main/uc_eco_main.module; @ 647
So I'm wondering if this is an ECO issue or if it is something that can be handled by the UC predicates setup? Is there more to this feature of ECO that I haven't noticed?
My understanding of predicates is that they can alter the UC cart after receiving confirmation messages from exterior checkout apps. To me this means that they'd both come back to the same location, cart/checkout/complete and thereby fulfilling the uc_eco_main_menu_alter(&$callbacks) function. I might be wrong in this understanding, what do you think?
Comment #13
WebNewCastle commentedWow, sorry I haven't been by to respond. It's been crazy busy for a long time, but I think I see an opportunity to set some time aside for this and other modules in the weeks ahead. If not before Thanksgiving (U.S.), then I'm planning to spend time after. So I will try to look at this again soon.
It would be good to get this module to the point of handling more use cases / payment scenarios, etc., before working on adding some additional features I've been considering. I want to look more closely at some of the session items too. I recently was tackling a situation with a checkout error that ended up being an issue a session cookie getting destroyed ... and eventually I found it was linked to CSS and page not found errors (images) related to having Colorbox installed. And my only point with this is that sometimes things that seem so completely unrelated have a cause and effect relationship.