We now have a new source of truth. You shouldn't use a feature toggle
without adding it to OpenFoodNetwork::FeatureToggle first. All toggles
are added at boot time already.
So you can easily inspect and activate new features without trying to
use them first. It brings more visibility and will enable us to easily
remove retired features as well.
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.
This enables toggling features as best fits us in each case. With this
new approach we can then toggle :customer_balance to an entire instance,
which is what we want in France.
This makes it possible to deploy it without releasing it to users since
the toggle is not enabled for anyone.
It aims to make the balance calculation consistent across pages.
This enables showing features to individual users only, which enables us
to deploy features that are not yet released to gather feedback from
product and testing, while no users have access to it.
A FeatureToggle could be switched via a class_eval in an initializer.
The initializer was installed via ofn-install. We want to get rid of
custom, untracked initializers. Here I'm changing the FeatureToggle
class to use environment variables instead.
This change needs to be followed up with a change in ofn-install to use
the new environment variable. It affects only Australian production.
This removes ten old overrides of the Spree view. Since the Spree view
is not used any more and got completely replaced by custom views, the
overrides were just adding noise to the code base.
