Juan, I added your patch into my local buildout, but it looks like it results in shipping always being free. Apparently setupShippingOptions in CheckoutSelectShipping (Producst.PloneGetPaid/browser/checkout.py line 738) is called both before the shipping choices are shown, and after it is selected.
I've noticed that the shipping plugin is called multiple times. That is a separate issue, but it really slows down the checkout process, especially if your shipping module makes use of a remote web service (like USPS or UPS). If anyone else has ideas or suggestions I'd love to hear them. Thanks -Rob On Tue, Jan 12, 2010 at 10:36 AM, Rob LaRubbio <[email protected]> wrote: > I just wanted to start this thread up again. This issue exists in the bug > tracker as issue #274. Also since I sent this mail I rolled back my fix > since it actually had the effect of always producing free shipping. > > Juan, I"ll add your patch to my local buildout and test it. If anyone has > thoughts or ideas for the real fix I'd love to hear them. > > -Rob > > On Wed, Jul 1, 2009 at 8:57 AM, Rob LaRubbio <[email protected]> wrote: > >> Sorry for the slow reply on this. My gmail stopped forwarding to my >> normal email so I missed this. >> >> After digging into this I came to the same conclusions and an almost >> identical patch. The problem goes a little deeper then the variable being a >> list since there is code in the checkout process to handle a list: >> >> def getShippingMethod( order, service_code ): >> """ decode a shipping code, and return the shipping method to be used >> or None """ >> if not service_code: >> return None >> >> if isinstance( service_code, list): >> service_code = service_code[-1] >> >> What I couldn't figure out is why the list is actually getting deleted at >> some point in the processing. As far as I can tell the request variables >> are held in two places in the request. Once as key/value pairs directly on >> the request, and in a dictionary called form on the request. It looks like >> some parts use just request and others use request.form so there is code >> that copies values from request.form to request and that is blanking out the >> value. What I can't figure out is why the value is blank in one but not the >> other. >> >> So long story short I went with a similar patch to yours: >> >> def make_hidden_input(*args, **kwargs): >>> '''Construct a set of hidden input elements, with marshalling markup. >>> >>> If there are positional arguments, they must be dictionaries. >>> They are combined with the dictionary of keyword arguments to form >>> a dictionary of query names and values. >>> >>> Query names (the keys) must be strings. Values may be strings, >>> integers, floats, or DateTimes, and they may also be lists or >>> namespaces containing these types. All arguments are marshalled with >>> complex_marshal(). >>> ''' >>> >>> # There has to be a better way, but I haven't found it. Essentially >>> # Allowing this to be a hidden variable results in an array coming >>> # back in the request when the user starts to move through the >>> process >>> # again. Somewere that populated array is replaced with an empty >>> array >>> # setting the shipping cost to 0. This only happens if the site has >>> # shipping set up and the user hits 'Back' from the review and pay >>> step >>> if kwargs.has_key('form.shipping_method_code'): >>> del kwargs['form.shipping_method_code'] >>> >> >> I'll be checking in my 'fix' shortly. >> >> However I notice that the Products.PloneGetPaid repository seems to have >> changed. I'll check my mails to see if it was intentional, but when I did >> an update this morning I got what looks like a new src and trunk directory >> in src/Products.PloneGetPaid. Both seem to contain the complete set of >> code, so now I seem to have three copies. (src/Products.PloneGetPaid/src, >> src/Products.PloneGetPaid/trunk & src/Products.PloneGetPaid/Products) >> >> -Rob >> >> >> 2009/6/23 Juan Carlos Coruña <[email protected]> >> >>> Hi, >>> >>> I think I understand the strange behaviour. I'll try to explain it: >>> >>> The first time you select a shipping the >>> request.form['shipping_method_code'] doesn't exist, hence it will be created >>> with the value you have selected in the wizard >>> (request.form['shipping_method_code'] == 'usps.D-16'). In the next wizard >>> getpaid gets the shipping cost using the value from the request. This time >>> it works. When you go back from this wizard to the previous one (to the one >>> you selected the shipping) the request.form['shipping_method_code'] exists >>> already with the previous selected value. Now you select the shipping and >>> continue. Getpaid doesn't create the request.form['shipping_method_code'] >>> because it already exists, so it APPENDS (creating a list) the new value >>> (request.form['shipping_method_code'] == ['usps.D-16', 'usps.D-16']). In the >>> next wizard Getpaid tries to get the shipping cost using the value from the >>> request, but this time resulting in NO success, because the value is a list >>> of two strings and doesn't match with any of the shipping methods. So >>> getpaid sets the cost to 0 and the shipping method to none. The next time >>> you go back the request.form hasn't the key shipping_method_code, so it >>> works as in the first time. >>> >>> I don't know where getpaid accomplishes all this, but I have a patch that >>> correct this strange behaviour. I know it's not the perfect solution, but >>> for now it works. Maybe someone that knows getpaid better than me can >>> correct the bug in the origin. >>> >>> Here is the patch: >>> >>> --- Products/PloneGetPaid/checkout.py.orig 2009-06-23 >>> 23:42:42.000000000 +0000 >>> +++ Products/PloneGetPaid/checkout.py 2009-06-23 23:25:11.000000000 >>> +0000 >>> @@ -714,6 +714,8 @@ >>> and returns a list of them for the template to display and the >>> user to choose among. >>> >>> """ >>> + try: del(self.request.form['shipping_method_code']) >>> + except: pass >>> siteroot = getToolByName(self.context, >>> "portal_url").getPortalObject() >>> ship_service_names = >>> IGetPaidManagementOptions(siteroot).shipping_services >>> >>> >>> 2009/6/23 Juan Carlos Coruña <[email protected]> >>> >>> Hi, >>>> >>>> I'm also trying to track down the same bug. It's a strange behaviour one >>>> time it works ok and the next time it fails, and so on... >>>> >>>> I have used the pdb and I followed the code till PloneGetPaid/_patch.py >>>> and there I get lost. I suspect the bug is in _patch.py, but I cannot >>>> assure >>>> it. Maybe this can be clue for others trying this. I'll continue to track >>>> down this bug. If I make some progress I will inform about it. >>>> >>>> 2009/6/23 Rob LaRubbio <[email protected]> >>>> >>>> I'm trying to track down a bug in getpaid that seems to allow a user to >>>>> get free shipping. I've been able to get to a point were I can reproduce >>>>> it, now I'm looking for pointers or help on why it is occuring. >>>>> >>>>> I've got a simple setup of Plone 3.1.6 with GetPaid 0.7.9 (I'm using >>>>> the svn checkout of the buildout). I've marked a couple of items as >>>>> shippable and have written my own shipping addon that talks to USPS. >>>>> >>>>> The free shipping issues happens when a user walks through the checkout >>>>> process up to the 'checkout-review-pay' step. At this point if the user >>>>> hits the 'Back' button provided on the page (not the browser back), they >>>>> return to the 'checkout-select-shipping' step with a hidden element that >>>>> holds their previous shipping choice. This input element is the same as >>>>> the >>>>> input radio select on the page. This shouldn't be a problem since I would >>>>> expect to get both the hidden value and the radio select in an array, and >>>>> it >>>>> looks like the code expects that as well since the getShippingMethodCode() >>>>> does this: >>>>> >>>>> if isinstance( service_code, list): >>>>>> service_code = service_code[-1] >>>>>> >>>>> >>>>> >>>>> however it seems I'm getting an empty array instead of an array with >>>>> two values. For some clarity the checkout-shipping-select html >>>>> essentially >>>>> looks like this: >>>>> >>>>> <form action="https://nwei.org/@@getpaid-checkout-wizard"; >>>>>> method="post" enctype="multipart/form-data"> >>>>>> <input type="hidden" name="shipping_method_code" >>>>>> value="usps.D-16"></div> >>>>> >>>>> <I removed all the other hidden inputs> >>>>>> >>>>>> <input checked type="radio" >>>>>> name="shipping_method_code" >>>>>> value="usps.D-16" /> >>>>>> >>>>>> <input type="submit" class="button context" >>>>>> id="form.actions.continue" >>>>>> name="form.actions.continue" value="Continue" /> >>>>>> </form> >>>>> >>>>> >>>>> As far as I can tell the code should work. I'm not clear on why >>>>> self.request.get('shipping_method_code') is [] on the second submit >>>>> instead >>>>> of ['usps.D-16', 'usps.D-16']? Also if I submit the form, then hit 'back' >>>>> again it works ok since there is no hidden element for an empty array >>>>> added. >>>>> >>>>> Anyway if anyone has some suggestions on where to look I would really >>>>> appreciate it. Thanks. >>>>> >>>>> -Rob >>>>> >>>>> >>>>> >>>> >>> >>> --~--~---------~--~----~------------~-------~--~----~ >>> You received this message because you are subscribed to the Google Groups >>> "getpaid-dev" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected]<getpaid-dev%[email protected]> >>> For more options, visit this group at >>> http://groups.google.com/group/getpaid-dev?hl=en >>> -~----------~----~----~----~------~----~------~--~--- >>> >>> >> >
-- GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker) You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en?hl=en
