This option came from Spree and we never used it. The config input field
is disabled in the admin interface and I checked our managed databases.
I don't think that we will want this feature in the future either.
Staging sends unmodified emails which is more realistic and we haven't
had a use case to intercept those emails. There's still the BCC option
if we need additional access.
Forking worked in theory but crashed the browser in system specs. It
also came with many other hurdles and isn't well known solution in the
Rails community. Sidekiq can give us better control over execution
limits as well.
The products in an order may require several shipping categories like
refrigeration or express. We now filter the categories according to
their support of shipping categories.
New Rails apps come with this class already, the job generator creates
it for every new job and Rubocop requires it as well. Let's make our
lives easier and use the same structure as other Rails projects. This
class may be handy one day.
Sidekiq doesn't have any features to limit memory usage or execution
time. We need a separate process for this. Forking avoids the boot time
of a fresh process and copy-on-write ensures minimal memory overheads.
ie truncate 12.50001234 to 12.5
When using imperial, the scalling calculation rounding results in value unit
having extra decimal when converted back to imperial
+ related spec
Before this schedules were being deleted when the Checkout Options step of editing order cycles was saved because this step wasn't sending the :schedule_ids parameter. It's more awkard for API users if they always need to explicity send the :schedule_ids parameter even if they don't want to add/remove any of the schedules, for example if they just want to update an order cycle name.
Before if a shipping method was shared between multiple distributors it could only be disabled/enabled on that order cycle for all the distributors which have that shipping method e.g. you couldn't select that shipping method for one distributor but disable it for another.
Before the OrderCycleShippingMethod had a validation which checked the shipping method belonged to the order cycle distributor. Instead of this validation this just ignores shipping methods which don't belong to one of the order cycle's distributors when they are being attached in the OrderCycleForm service. This pattern is already being used in the OrderCycleForm service for ignoring Schedules that the person doesn't own.
Co-authored-by: Maikel <maikel@email.org.au>
Before the Shop::OrderCyclesList service would return order cycles even if they are not ready for checkout and we had a check before calling the service in BaseController which would return OrderCycle.where('false'). It seems like this check should be part of the service too.
It's a clearer name because 'preferred' implies there could be other unpreferred shipping methods available as well.
Co-authored-by: Maikel <maikel@email.org.au>
It makes things much simpler if we return all shipping methods by default without needing OrderCycleShippingMethod records to be added to the database.
Co-authored-by: Maikel <maikel@email.org.au>
