I can’t quite understand what is the intent of that class by checking the git history. Aren’t we overriding the payment and shipping methods that the customer specified to place the order? Can you @oeoeaio shed some light on this?
This class is part of the system that charges hubs for using OFN. It does so by creating orders. These are not orders for food that customers place, but instead are orders for OFN usage, so to speak. Thus, they’re technically not “shipped” anywhere, so they’re just given a default shipping method. @oeoeaio wrote this and should be able to confirm.
The “orders” used by this class are not real orders, they are basically “invoices” that enterprise owners need to pay for use of an open food network instance. The amount that the enterprise owner is charged is configurable by the instance, and can be based on a combination of a percentage of their turnover, fixed fees, caps and floors and trial periods. The “orders” you are seeing here are just objects to hold the billing information for a particular enterprise owner for a given month. From memory, the only reason they have a shipping method at all is because there is a validation on Spree::Order that requires it. It is not important for the functionality provided, so I think if we get to that point the code that updates shipping_method_id can be safely removed.
This was truly unexpected. Needless to say someday we’ll have to implement this in a proper way or we’ll end up extending the Order model in strange ways for this feature to work.
I will add some documentation to the class so the next reader is aware and make my way for the upgrade.
Validations on orders are dependent on the order state so maybe it just isn’t being triggered? I am fairly sure that some kind of error will be encountered when trying to process an order to completion if it doesn’t have a shipping method, though it may not be a validation error, I can’t recall…