The admin UI shows only features which were added to the database. We
always had to look up a feature's name add it manually before we could
enable it. Now it will appear in the UI after some code asked if it was
enabled.
This only adds a database query once when the feature doesn't exist yet.
The `feature.exist?` call only performs an in-memory lookup in the
memoizer.
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.
Note, this doesn't test checking/unchecking some distributor shipping methods and not others because that is tested in order_cycles/complex_creating_time_specific_spec.rb.
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.
The spec was failing from time to time. I hope that this will fix it.
```
Failures:
1)
As an administrator
I want to create/update complex order cycles with a specific time
creating an order cycle with full interface
Failure/Error: fill_in 'order_cycle_outgoing_exchange_0_pickup_time', with: 'pickup time'
Capybara::ElementNotFound:
Unable to find field "order_cycle_outgoing_exchange_0_pickup_time" that is not disabled
# ./spec/system/admin/order_cycles/complex_creating_specific_time_spec.rb:138:in `add_distributor_with_fees'
# ./spec/system/admin/order_cycles/complex_creating_specific_time_spec.rb:66:in `block (2 levels) in <main>'
# ./spec/system/support/cuprite_setup.rb:39:in `block (2 levels) in <main>'
# -e:1:in `<main>'
```
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>
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.
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>
