The warning first displays "Saving..." before confirming changes are saved.
I'm not entirelly sure, but it seems that asserting on this first, before asserting on other page elements stabilizes the spec.
It looks like we have a new race condition that may only be a problem in
specs. If you trigger one report, it displays via websockets and then
you trigger the next report, there may still be some Javascript active
that displays the first report while the second one is loading. I'm not
sure if users would navigate that fast though.
To minimise the problem, I adjusted the polling to leave more room for
the default websockets response.
This also resolves a race condition scenario. Even if the report gets
rendered via websockets before the controller response is rendered then
the fallback script loads the report again. It's not the most beautiful
but probably okay until we replace websockts altogether.
I'm leaving websockets in at the moment because it can render the report
much quicker than polling can.
I'm adding TurboPower for the scroll_into_view action. It adds all the
nice CableReady actions to Turbo Streams.
Note that I omitted `block: "start"` because that option is the default
in Javascript. And the generic `action` method doesn't support
parameters like this anyway. I'll work on that in the next commit.
I also re-introduced a race condition by rendering the "loading"
indicator after triggering the report rendering job. I'm planning to
resolve that later.
- 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
The preference will be set from the admin interface in a new commit
It would be nice if we had an array/list type for preferences. Probably not too hard to implement, but this will do.
A spec was referring to and input id:
```
"order_cycle_incoming_exchange_0_variants_#{new_product.variants.first.id}"
```
But sometimes the exchange would have the id 1 instead of 0 and the test
would fail. Instead I opted to select the field by text visible to the
user.
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 allowed this for producer stock and need to do the same for inventory
stock. This will allow us to create backorders for missing, but promised
stock.
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.
