The previous version wasn't testing anything as there was no fees set
up.
Now we check that fees are applied as expected, and also that supplier
fees are applied only to the expected product.
I found that a delay in the reflex handling the request could fail the
spec. Added a sleep in the reflex to reproduce the fail. The I added
expectations for the page content to wait until the page was updated and
that fixed the specs.
We were trying to assert values in the database withou waiting for he
update to finish. First expecting the changed values on the screen
ensures that Capybara waits for the action to finish. Then we can check
the database.
Although the change fix the issue in the back office scenario, it has
the side effect of getting the order total out of sync. Updating a
payment adjustment need to be followed by udpating the order total and
payment amount to keep everything in sync.
- As we are only showing the oc warning once now we need these steps where we are dismissing the oc warning after each navigation. Just keeping the first notice dismiss after login
- when update on adjustment in payment, recalculation of
correct adjustment was not done
- the corresponding spec
- an id to easy the finding of the change of fees in the spec
The orders file is too big and causes a bottleneck for parallelising specs.
Maybe they should be merged with the above specs, but I'm not familiar enough to know for sure.
- removes the pending
- add the click to go to the 'Order Details' page
to check for the 'shipped' status
- from enqueued to have_been_enqueued so the spec
is flaky-free
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.
