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.
