As part of this PR https://github.com/openfoodfoundation/openfoodnetwork/pull/10329
LocalisedNumber validation was tightened, but that means negative number
were not valid anymore.
This commit has been cherry-picked after this fix has already been
applied. Now we just change the order of characters in the regex because
humans are used to reading the minus at the beginning of the number. But
this change doesn't change the logic at all.
This option came from Spree and we never used it. The config input field
is disabled in the admin interface and I checked our managed databases.
I don't think that we will want this feature in the future either.
Staging sends unmodified emails which is more realistic and we haven't
had a use case to intercept those emails. There's still the BCC option
if we need additional access.
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.
This makes a clear distinction between the unfiltered and filtered list.
There may also be some gotchas when modifying the array of an
ActiveRecord relation. It also allows us to write shorter code without
storing a separate variable.
The applicator converts the input to an array, even `nil` becomes an
empty array. Iterating over an empty array doesn't do anything either,
the result is the same.
I changed the used parameter names within the report so that we don't
have to rename the given parameter names when the report runs. This
avoids modifying the `params` object and therefore other problems.
The Enterprise Fee Summary report modified the `params` object. So when
we pass the same `params` a second time to the report class it doesn't
find the same values. In some cases that would lead to a server error.
The next commit implements a better solution though.
This is supposed to lower the memory footprint of all Puma workers. The
reports code will occupy needed memory in one Sidekiq worker instead of
in several Puma processes.
The current code doesn't limit the execution time yet. We either need a
way to terminate the report rendering after a while or send an email
with a link to access a rendered report.
