There is no easy way to make the original product invalid, but we can
make sure the cloned product will be invalid. The cloned product add
"COPe OF " in front of the product's name, so by starting with a name
that's long enough, the cloned product will have a name longer that 255
char and will then be invalid.
We now know which errors to expect. We still let other unknown errors raise higher up, where they will be logged with BugSnag, and treated as internal_server_error.
It turns out that the duplicator still raises an exception in some cases. Now I think I see why the the controller was catching the exceptions. At least now we know which exceptions to catch.
Instead of using the auth method name, let's just not supply username
and password when we don't want to authenticate. The two affected
servers AU and CA don't have credentials set anyway. This is compatible.
The specs needed changing though.
These config values are relatively static but in some cases they can be called many times in the same request (like rendering a report or a large list of line_items in BOM). These values will now only get fetched from Redis/Postgres once at most per request/job.
This was effectively being done before for the product's sku (stored on the master variant) via the #duplicate_variant method, but now it needs to be done explicitly on the product in #duplicate_product
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.
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`.
```
This only makes sense in the context of Products which only have "master" variants, and we removed that option a while back.
Remove #variants? check from ProductStock concern
The previous mechanism didn't seem to work and newer Rails versions have
an easier config for this now.
Also fixing all i18n errors which were now failing specs.
This fixes the following deprecation warning
```
[DEPRECATION] `html` is deprecated - use `html_wrap` instead. Please
note that `html_wrap` will wrap all parts of currency and if you use
`with_currency` option, currency element class changes from `currency`
to `money-currency`.
```
This removes millions of deprecation warnings like the following
```
[DEPRECATION] `symbol_position: :before` is deprecated - you can replace it with `format: %u %n`
```
from the build. It gets printed every time a `Spree::Money` is instantiated.
This should result in a non-negligible speed up of the test suite.
This is already tested by the top-most before block and besides, we
there's no OFN in Japan. We don't need to test all supported currencies
but ensure that the various arguments work as intended.
