The idea around merging carts and orders into one makes sense in all the ways you discussed - let's try that and see where it goes.
Thanks a lot Alex. On Wed, Dec 10, 2014 at 7:17 PM, Alexander Hill <[email protected]> wrote: > > Lots of good points there. > > I suppose I have unconsciously been thinking about this from the > perspective of someone who needs to take payments via external POST, and > also happens to want the unfinished orders hanging around as well. So > cleaning up and hiding the unfinished orders didn't occur to me. > > I agree that this change doesn't warrant all of that, and I would be happy > with an easier way to make this configurable. One easy thing we could > change would be to make sure Cartridge's OrderForm works nicely if passed > an instance. I have no idea how far this is from being the case currently > (missing argument to __init__ aside). I'll have a play with this shortly. > > > Hmmm... > > Another somewhat (!) more invasive idea is to unify orders and carts. I > think that could actually simplify Cartridge quite a lot, as there's a lot > of code marshalling data between sessions, carts and orders currently. Let > every order begin as a cart, and simply add data to it as the user > progresses through the checkout and payment steps. The status field would > indicate how far the order has come – cart, checkout, payment, complete, > processed. > > We would be able to clean out old unfinished orders for free – we already > do that with carts. As a bonus, we'd also get user-based carts for free, > since carts/orders would have the user_id field set. We would satisfy the > use cases mentioned in this thread, and simplify the code and schema. > > Big change I know, but what do you reckon? > > Cheers, > Alex > > > On Wed, Dec 10, 2014 at 2:05 PM, Stephen McDonald <[email protected]> wrote: > >> I don't know, which means I guess I'm not set. I understand the desire >> for it, but I've always felt it's important with Mezzanine and Cartridge to >> reject certain features, even when they'd be useful to someone, especially >> when they start to compromise the original intent of how things have been >> designed. >> >> So I suppose If it could be implemented simply enough with a setting, >> then sure - but what does it really entail? >> >> It would need some documentation around it, describing why unfinished >> orders get left floating around, and how they could possibly be cleaned up. >> It'd even best be up to Cartridge to provide the management command that >> does that, and notes in the documentation on how it can be used as a cron >> job. >> >> The SHOP_ORDER_STATUS_CHOICES will need something like an "Unfinished" >> status as well. Then the admin will need support too - if unfinished orders >> remain in the db, it really makes no sense for them to appear by default. >> >> You can see one seemingly small option controlled by a setting really >> does have a flow-on effect throughout the project, which is a major part of >> why I don't want it. Is this really not something that can be implemented >> by doing away with the final checkout step views of Cartridge, and just >> using something custom? >> >> Actually a better question might be - how can we make this configurable >> somehow, without actually implementing "order objects get created before >> payment" feature? Could we not break the checkout form (which I recall as >> being swappable via a setting) up into enough overridable methods, that >> control the behaviour, similar to how a lot of class based views work? >> >> On Wed, Dec 10, 2014 at 4:45 PM, Alexander Hill <[email protected]> wrote: >> >>> My understanding is that if CC details touch your server, even in >>> memory, you need to be compliant. The official PCI body says "The DSS >>> globally applies to *all* entities that store, process or transmit >>> cardholder data" at >>> https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf >>> >>> I agree that Cartridge's simplicity is a strength, but I don't feel that >>> adding this feature will compromise that. Are you pretty set on this, or is >>> it worth me making a branch and seeing if it can be done without >>> complicating things too much? >>> >>> Cheers >>> Alex >>> >>> On Wed, Dec 10, 2014 at 10:11 AM, Stephen McDonald <[email protected]> >>> wrote: >>> >>>> There was a lengthy mailing list discussion on this years ago where >>>> everyone agreed that there shouldn't be unfinished orders floating around >>>> in the database. >>>> >>>> I still agree with that and I'm not particularly keen on the idea of >>>> having to maintain this as an option and feature. Cartridge is >>>> intentionally very simple and limited compared to the alternatives, I'd >>>> rather keep it that way. >>>> >>>> BTW I naively assumed that Cartridge dealt with credit card handling >>>> well enough from a PCI-DSS perspective - the card number doesn't get >>>> stored anywhere and is only posted from one checkout step form to the next. >>>> >>>> >>>> On Wed, Dec 10, 2014 at 1:03 PM, Alexander Hill <[email protected]> >>>> wrote: >>>> >>>>> Hi Josh, >>>>> >>>>> I'm interested to hear from Steve too. Since Cartridge was initially >>>>> written to call payment processors from the server, only creating the >>>>> orders after payment was submitted makes sense it makes sense – doing so >>>>> earlier does introduce a bit of extra complexity. Keeping the cart in >>>>> sync >>>>> with the order if the customer gets up to the payment step and then adds >>>>> items, for example. >>>>> >>>>> I remember reading through cartridge-payments a couple of years back. >>>>> I'm a bit wary of side-effects in forms (like saving the order object). >>>>> That said, it's a clever way of getting it done without any custom view >>>>> code, which is what I'm doing. I might copy it :) >>>>> >>>>> Am I missing something or is the added callback_uuid field not >>>>> strictly necessary? The order number should uniquely identify the payment >>>>> anyway. >>>>> >>>>> Cheers, >>>>> Alex >>>>> On Dec 10, 2014 12:45 AM, "Josh Cartmell" <[email protected]> >>>>> wrote: >>>>> >>>>>> I like the idea of having an order ID before payment (for the reasons >>>>>> you outlined) but I'd be curious to hear if Steve had any particular >>>>>> reason >>>>>> for not doing this when he originally created Cartridge. >>>>>> >>>>>> Also, in case you haven't seen it you might want to look at >>>>>> https://github.com/explodes/cartridge-payments >>>>>> >>>>>> On Mon, Dec 8, 2014 at 9:39 PM, Alexander Hill <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I don't want credit card details touching our server for PCI-DSS >>>>>>> reasons and have a no-Javascript constraint, so I use direct POST with >>>>>>> our >>>>>>> payment processor. In my project I create an Order instance before the >>>>>>> payment page is displayed, so that I'm able to pass the correct order >>>>>>> number to my payment processor. >>>>>>> >>>>>>> I remember seeing a similar workaround in someone else's payment >>>>>>> processing code a long time ago so I assume this kind of thing might be >>>>>>> useful to more than just me. It's quite messy to bolt on aftermarket, >>>>>>> so I >>>>>>> propose integrating it into Cartridge, probably toggled by a new >>>>>>> setting, >>>>>>> SHOP_CREATE_ORDER_BEFORE_PAYMENT or similar. >>>>>>> >>>>>>> This change also has the helpful side-effect of allowing one to >>>>>>> query incomplete orders – I have a job that sends a daily email summary >>>>>>> of >>>>>>> incomplete orders to sales staff, for example. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Mezzanine Users" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Mezzanine Users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Mezzanine Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Stephen McDonald >>>> http://jupo.org >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Mezzanine Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Mezzanine Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Stephen McDonald >> http://jupo.org >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Mezzanine Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Mezzanine Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
