Creating a variant actually create an extra one via the associated
product, as it will create a "standard variant".
As far as I can see there is no way around it, but it should be fixed
once the Product refactor is finished, and product becomes product
group.
Added a comment on the variant factory to explain the problem.
It's not ideal as it will slow down the test suite a little, but I think
it's better to write the code the way you would expect it, and it will
eventually get fixed.
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.
- Cop: Rails/RelativeDateConstant
- raises offense if Constant is relative data (ie: since, ago)
- Reason: relative data will be evaluated only once
- BUT here, Date should not be evaluated in a class method, and have a different
- value for each call. But the data should be the same for an instance
- Therefore: move the ago in init method
- Cf. https://docs.rubocop.org/rubocop-rails/cops_rails.html#railsrelativedateconstant
- Since there is no constant to be called form a class, but a date from an instance, the
spec has been modified accordingly. The RemoveTransientData.new.call had to be splitted.
So it turns out that all these features are built into the report framework.
LineItems includes complete_not_canceled_visible_orders.
It even takes care of masking non-editable orders.
We weren't bothering with stock when items were on demand anyway. But we
want to track stock now so that we can backorder more when local stock
levels become negative.
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.
The new product image import spec was loading rake tasks multiple times.
That make the spec for enterprise deletion fail when executed afterwards
because the deletion task was executed twice and failed the second time.
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.
