There's a user-facing change here. When you tried to update the quantity
of a line item beyond available stock, two things used to happen:
1. A warning was displayed.
2. The item's quantity was updated to the highest possible.
Unfortunately, the logic to update the line item was also reloading the
page and the warning message disappeared before it could be
acknowledged. The easiest fix was to skip the update request. And in my
opinion, it's even better to let the user decide if they still want to
update or cancel the update.
Eventually, we want to replace all this custom Javascript logic with
StimulusJS anyway. So let's not put too much effort into this. It was
important though to resolve the flaky spec which made many builds fail.
I chose to use the 'elements' collection rather than choosing which elements to include (ie this supports inputs, textareas, buttons and anything else I didn't think of). It could be a bit simpler if we assume the element is a form. Even simpler if it's a fieldset (that has a disabled property). But I didn't want to limit it too much.
Unfortunately JS is quite ugly compared to Ruby. And 'prettier' made it uglier in my opinion.
Trying to cover it more comprehensively, and revealing we have a lot of behaviour to update.
Products and their variants should always get saved (or not saved) together. This is considered the most intuitive behaviour.
There's still duplication with the "variant has error" context, but I try to avoid nesting shared_examples, it starts to get ugly. Happy to discuss though.
Rails is registering a driver called `cuprite`. And when we did that as
well the driver got registered three times somehow. It looked like our
driver options were used in the end but just to clarify I gave it a
unique name.
This was inspired by:
* https://github.com/ViewComponent/view_component/pull/1877
It suggests that it may avoid dead browser errors on CI. We'll see.
We now check if the shipping method changed before we actually select
it. Fix the related spec.The spec was wrong because order.select_shipping_method
fails silently. That means the shipping method wasn't getting
updated on the order, thus the test was passing.
from old bulk product screen. Hmm I just realised we're deleting that screen soon anyway.
But this helps clean up the spec before I refactor it further.
I though that once the shipping method was set it's available on the
order, but apparently it's not always the case. At least some of the
test scenario have order with no shipment, thus no shipping method set.
We need to recalculate the voucher adjustment(s) in the following
scenarii :
When a voucher as been added to the order and :
* Moving to the payment step from details step, to take into account
potential change in shipment fees. (this happen if we return to the
details step after reaching the summary step)
* Moving to the summary step from payment step, to take into account
payment fees
