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.
This makes a clear distinction between the unfiltered and filtered list.
There may also be some gotchas when modifying the array of an
ActiveRecord relation. It also allows us to write shorter code without
storing a separate variable.
Allowing creation and deleting via the user association.
It probably won't be much effort to allow editing and multiple records, but I cut it down to the minimum needed to avoid any further delays.
I couldn't find a way to test a failure in the destroy method, but decided to keep the condition because I thought it was worth having.
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
In 2019 Pau observed an error where an empty attributes hash was passed
to the bulk product update method. He added an automated test but wasn't
able to reproduce the error.
A recent change in logic made the spec fail but rspec-retry hid that
fail because it would succeed on a second try (not sure why). I now
changed the logic to ignore empty attributes properly and avoid an error
trying to create a new variant when no attributes are given.
* f940397781 Pau's spec
* 6f228781d4 Fixing error detection
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.
