```
Fix deprecation warnings around class loading during initialization
Thi2022-11-08T08:54:57.542Z pid=40093 tid=nl9 WARN: DEPRECATION WARNING: Initialization autoloaded the constants ReportsHelper, DateTimeStringValidator et IntegerArrayValidator.
Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload ReportsHelper, for example,
the expected changes won't be reflected in that stale Module object.
These autoloaded constants have been unloaded.
In order to autoload safely at boot time, please wrap your code in a reloader
callback this way:
Rails.application.reloader.to_prepare do
# Autoload classes and modules needed at boot time here.
end
That block runs when the application boots, and every time there is a reload.
For historical reasons, it may run twice, so it has to be idempotent.
Check the "Autoloading and Reloading Constants" guide to learn more about how
Rails autoloads and reloads.
```
I can't find any reference to this in the code. The wiki says maybe it's looked up with a variable, but I don't see how it could be used unless this string is defined in code somewhere (we wouldn't translate data from the database, would we?).
Maybe it's used in a gem? In that case, hopefully CI will pick up the error.
We define it in the dotenv files already which has the advantage of
being overridable. I adjusted the dotenv files to have the same value as
was set before, 30 times `x`.
Before there was a row for each distributor and a 'shared' row for shipping methods which were shared among more than one distributor. This layout displays a single list of shipping methods with the distributor or distributors it belongs to beside it as suggested by @lin-d-hop
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>
