This fixes lots of specs like the whole
spec/controllers/shop_controller_spec.rb, almost all specs of
spec/lib/open_food_network/products_renderer_spec.rb and most of
spec/features/consumer/shopping/shopping_spec.rb.
This removes the need to expose supplier_ids through #<< and makes both
ResetAbsent and its strategies simpler.
This could be made even simpler if the strategies just implemented
`#relation` as public method and ResetAbsent called `#update_all` on
them. The data to be fetched is the only thing that changes but the
update is the same.
No need to go through half of the algorithm if the setting is not
enabled. It does not change per enterprise.
This also assumes "Previously we were updating both (products and inventory)
at the same time during one import, but now it's one or the other" in
Matt's words.
This also turns local vars into ivars so that the behaviour can be
thoroughly tested. These ivars are meant to be removed once this class
is refactored further. Now there's no other way to ensure its state.
This may lead to more error reports than we want to see. A not existing
email address may cause Bugsnag to be notified. If this happens, we can
rescue form these specific errors and only report the rest.
The most common failure would happen when sending the confirmation email
triggered by `user.save`. We rescue any errors here and give feedback to
the user.
This allows for immediate feedback when the user types an email address
that is not accepted by our mail server or the email setup is not
configured properly.
Using deferred methods on the user model breaks delayed jobs when the
user is deleted while the job still exists. We could create a proper job
referencing a user id for sending these emails instead. But since the
user has to wait for the confirmation email anyway, we can send it
within the current request. This should be revised if performance
becomes an issue.
Sending the email directly also has the advantage that we can tell the
user if emailing failed. See the following commits.
This change impacts a bunch of specs as we now need a working email
setup to create unconfirmed users. This commit introduces a custom
matcher to unify testing for confirmation emails.
The route and controller were in the main app and the views in the engine, with this commit they stay all inside the engine
This is done to keep it simple and remove the unnecessary dependency between main app and engine
If we use this mechanism in the future for other things in the main app or other engines, we can find a way to extract/abstract this
