Per review, the check is done on the same enterprise as the one use to
initialize ScopeVariantToHub. So it makes sense to move the actual
feature check to ScopeVariantToHub#scope
We have only one role, so let's get rid of the unneeded method.
Now we are in a better place to get rid of Spree::Role and replace it
with a simple boolean.
This was actually shown in one place and represents a user-facing
change. But you weren't able to edit the field which means that only
very old enterprises would have had this field set and were not able to
change it anymore.
I searched au-prod and found the following values in the database:
- "Friday 31st January"
- "From 4pm, Monday 30 September"
- "From 5pm-7pm Monday"
- "Saturday 27 April 12noon"
- "January 31st/February 1st"
- "Saturday 1st February"
They seem specific to a certain order cycle and have no value as
fallback any more. Seems safe to remove.
- presence: true is redundant since Rails 5.0 BUT applies
with new default config of
belongs_to_required_by_default to true
Lots of files with belongs_to_required_by_default = false
(backward compatibility)
So: deleting this setting implies to adding optional: true
- added 'NOT NULL' constraints so model constraints match
with contraints on DB tables.
- updated the todo
It would take ages to go through all files now and assess all belongs_to
associations. So I just declare the old default and then we can move on
and apply the new default for the application while these classes still
use the old one. All new models will then use the new default which is
the goal of this excercise and we can refactor old classes when we touch
them anyway.
Using the clever concurrency testing borrowed from SubscriptionPlacementJob, but I thought a shorter pause time (just 100ms) would be sufficient.
I considered doing this with a new 'state' field (upcoming/open/close), but decided to keep it simple.
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>
