Forcing manual order processing?

[racitup]

As we know, shipping is a difficult problem to solve.
How would I write a WorkflowMixin to allow manual shipping calculation and addition to an order?
And after doing that, is there a way to allow the customer to pay by stripe online in the normal way or must payment be done by PayInAdvanceWorkflowMixin?

[jrief]

Using a WorkflowMixin to calculate the shipping costs is too late, because then the order has already been created and the customers has already been charged.

If your Shipping Provider provides an API where you can query shipping costs, depending on the destination, weight and size, then the appropriate place to put that code is a customized ShippingModifier.

[racitup]

Okay, so my compromise is that I've added a shipping provider table which must be manually populated with shipping options for various destinations, accessed through a ShippingModifier.

However, I intend to only input some destinations to start with. If an order shipping address destination does not exist in the shipping options, what I would like to do is force a pay-in-advance payment provider, so that an order can be placed with the customer instructed not to pay it. Then I can add the shipping destination and ask the customer to place the order again, cancelling the original order. Or even better I may look into putting the order contents back into their cart somehow..

But my problem now is that the shipping address is not known until after entering checkout, and it looks like the payment providers are determined at the very start of checkout. The is_disabled() method of the payment modifier only removes payment options if I refresh the page after entering the shipping address and shipping method.

Could is_disabled() be used in the ajax checkout updates very easily?

[racitup]

So I've started making the changes to allow dynamic updates for the payment modifiers here, but I've found that somehow the response does not have the correct payment modifier options. It's like the cart is not fully up-to-date when the response is sent. Maybe the ExtraRows have not been processed. Any idea why?
CheckoutViewSet.upload() states "Afterwards the cart is updated, so that all cart modifiers run and adopt those changes." Whereabouts is that done?

[jrief]

Please check how your cart modifiers are executed. Remember that a shipping- and payment modifier is only executed if active. You can always invoke cart.update(request) to ensure that all modifiers have been called.

[racitup]

Ah I think I get it.. CheckoutViewSet.upload() runs form = form_class.form_factory(request, data, cart) (which runs cart.update(request) and is_disabled()), and then update_data = form.get_response_data() for each modifier form. But my payment modifier is_disabled() depends on the outcome of another modifier. So it depends in what order they are run.. but I thought all modifiers were run in the order they are declared in the settings?
I notice dialog_data = sorted(dialog_data, key=lambda tpl: int(tpl[1]['plugin_order'])) does some sorting first, what is that for?

[racitup]

It appears that 50% of the time my shipping modifier is run by either of:
form = form_class.form_factory(request, data, cart) <-- before form.get_response_data()
response = self.list(request) <-- after form.get_response_data()
in CheckoutViewSet.upload()
I guess because it is only active 50% of the time?

[racitup]

Okay, this appears to be a bug in the payment and shipping modifiers.
When form = form_class.form_factory(request, data, cart) is run cart.update(request) runs all modifiers. Modifiers run self.is_active(cart) to find out if they are active. Except the modifiers that are active in the database extra field which is used by is_active have not yet been updated. So the modifiers that are run do not match the request.

[jrief]

@racitup for me this description is not reproducible.

[racitup]

This is only a problem for dynamic updates since the form.get_response_data() is run before the cart.save(); but for the HTML checkout render, response = self.list(request) is run after cart.save() so this is not a problem.

[racitup]

Closing, see PR #600