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.
It looks like it was expected that the price and amount columns would be formatted, but this is not currently the case. So I cleaned this up to be less ambiguous.
If any of these columns were to be configured for formatting, this line could be added back to test for unformatted output.
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.
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 "subject" is usually the code under test. In this spec it would be
the TagRuleApplicator and not the parameter given to it. So I renamed it
to avoid confusion here.
Before it said:
```
WARNING: Using the `raise_error` matcher without providing a specific error or message risks false positives, since `raise_error` will match when Ruby raises a `NoMethodError`, `NameError` or `ArgumentError`, potentially allowing the expectation to pass without even executing the method you are intending to call. Actual error raised was #<RuntimeError: Cannot use t(".legacy_translation") shortcut because path is not available>. Instead consider providing a specific error class or message. This message can be suppressed by setting: `RSpec::Expectations.configuration.on_potential_false_positives = :nothing`.
```
I observed this data but I'm unsure about the root cause. It could be
that the SQL query fetching this data needs tweaking to return the fee
name in this case or it could be that it's not available (deleted).
In any case, I thought I document what's happening and make this
summarizer more robust before looking into the query.
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.
