We were already eventually removing the "success" border style on
inputs. I think it makes sense to do the same for the success message
itself. That's how our standard "flash messages" already work.
This is pretty black magic to me, but my understanding is that:
* When submitting customer forms, we use `$q.all()` on the result of
submitting each form asynchronously in order to decide whether to
display a success message (no errors) or a failure message.
* The value returned for each particular form submission was the return
value of either `change.scope.success()` or `change.scope.error()`.
These use the `switchClass` factory, which changes a particular DOM
element's class to the proper pending/success/error class, but in the
success case, it also sets a timeout to remove the class using
`$timeout()`, which is a promise, and that was its return value.
* Because of the above, `$q.all()` was actually waiting for the
`$timeout()` promise to be fulfilled before proceeding.
The fix is to not return a `$timeout()` promise from the `switchClass`
factory when a timeout is passed, but instead set a timeout on the
element, but return the element itself regardless.
* Keep save bar visible as long as there's a customer form displayed.
* Only display "You have unsaved changes" when there's any difference
from the original values. If form changes are reverted, hide that
note.
* Similarly, only let the button be enabled if there are any actual
changes to be saved.
I don't know why, but even though the client sends http accept header for json, rails is treating it as html. This was being overridden in the route, but I want to support multiple formats next. So, we explicitly choose the format by adding it to the request path.
Before if you did a bulk product update there was an error:
> TypeError: Cannot set property 'variants' of null
It only seemed to happen if pagination was required i.e. more than 15 products. It seemed to be happening because the default sort order on the products API endpoint which handles the bulk update is 'created desc' but 'name asc' on the /admin/products controller.
Another fix included here is for the sorting direction arrows which were not displaying on the admin products page. The sorting arrows require the sorting expression to be on the :sorting var instead of :q.sorting.
Fixes#6399
OFN API is now authenticating all users, if no session and no key is provided an anonymous user will be created so that user can access public endpoints, authorization is then done at each individual endpoint. This makes this spree api auth call irrelevant
`@loading` was set to false when the request with the last id finished.
But another request started earlier (having a lower id) could take
longer. `@loading` was set to false even though these long requests were
still active.
Currently, we always toggle "reverse" when triggering a sort.
If "reverse" is initially set to false, triggering a sort for the first
time then toggles this to true. The effect is that, the first time that
sorting is done, the rows are sorted in reverse order.
This is not intuitive - they should be sorted in ascending order first.
It seems that the success message on the customers page is disappearing before the spec can
detect it. This seems unlikely since it's present for 3 s, but this is my best theory right now.
