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>
Instead we will make sure the order cycle is not available on the shopfront if it is doesn't have valid shipping methods. This will preven the issue where if one distributor deletes their shipping method, we don't want to invalidate the order cycle for all other distributors.
Co-authored-by: Maikel <maikel@email.org.au>
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>
Specs should test public methods. Private methods should be able to
change without specs breaking.
The specs were also just mirroring the code and didn't really have any
meaning. So I wrote new ones which are hopefully clearer.
There's actually a case which I don't quite understand. Why don't we
require a customer for a new complete order? It means that we don't have
a customer creating it but then it's added when updating the order.
Seems inconsistent.
We configured Paperclip to convert images to JPG in some cases but I
omitted that here because we don't need it. If an image is better
represented as PNG or another format then the user should be able to
choose that.
Some specs were also testing the generated URL but the Active Storage
URL doesn't contain a style name anymore and it's not helpful to test
the URL.
The old Paperclip configuration was very clever and easy to use but it
was also a complicated implementation building on the complicated Spree
preference system.
I simplified this with Active Storage, storing simple references to blob
ids and default URLs as backup.
While we migrate from Paperclip to Active Storage, we need to use both
at the same time to avoid any downtime or lost images.
Once the migration is complete, we want to use the same name for
attachment as before. Using Paperclip and Active Storage at the same
time creates a name conflict on a couple of methods.
I'm using alias_method as a temporary solution to access Active Storage
methods. We will remove that after the migration. I declare Paperclip
afterwards so that we have those methods declarations for backwards
compatibility now.
