Note that, as explained in
https://apidock.com/rails/v3.2.13/ActiveRecord/Relation/delete, `delete` does
not trigger callbacks and so it skips the products cache logic.
If we still want to avoid instantiating the AR object, we need to explicitly
call that logic for the cache to be up-to-date.
This way we don't need to touch the class implementation to enable the
products cache in development. Just change the default value in
`app/models/spree/app_configuration_decorator.rb`.
Using the default fixes a missing translation. The text is slightly
changed but should be okay as well:
- "^Tax Category is required"
+ "Tax category can't be blank"
Our translations are not available when decorators are loaded. The
message for a missing product category was missing:
https://github.com/openfoodfoundation/openfoodnetwork/issues/1829
I moved the translation to ActiveRecord's default scope so that it can
be picked up automatically.
Relax controller permissions for enterprise fee summary. Even non-admin
enterprise users should be able to see these reports.
Filtering of data based on permissions is handled in:
* OrderManagement::Reports::EnterpriseFeeSummary::Authorizer and
* OrderManagement::Reports::EnterpriseFeeSummary::Permissions.
Enterprises have an `address_id` which must point to a valid
`Spree::Address`. As Rubocop suggested, I restricted the deletion of
addresses when they are still associated to an enterprise.
Without declaring `dependent: :restrict`, trying to delete the address
would raise `ActiveRecord::InvalidForeignKey`. Now it is more specific
and raises `ActiveRecord::DeleteRestrictionError`.
I didn't find code rescuing the InvalidForeignKey when deleting addresses. I
actually think that we never delete addresses. So this change should not
have any impact on the execution.
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.
