The key here is the enterprise_relationship. This is required for the supplier to have permission to see the orders.
Curiously, the unit test still passes. All will be revealed in the next commit..
Otherwise we would try to take stock from the producer stock level
without respecting their on-demand settings. So from now on:
If stock level or on_demand are set on the override then it's not using
producer stock levels.
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.
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.
