#update_column(s) skips callbacks (which is useful), but it doesn't change the updated_at field on the record by default (which we should be doing in these cases).
This change is made in Spree 2.2 here: b367c629ce
Fixes#6435 i.e. If the customer paid for their order by Stripe/Paypal then the Enterprise needs to know that the order was cancelled in order to arrange a refund. Refunds are not automatically processed when an order is cancelled.
This will send a very basic email to the shop, it only includes a link to view the cancelled order in the admin area initially.
I created a CustomerOrderCancellation object here because orders can be cancelled in two ways (1) by the customer, so an email should be sent to the shop. (2) by the shop, so an email doesn't need to be sent. However the code for cancelling order happens in Order#cancel via the state machine. Rather than passing some sort of parameter into #cancel to indicate whether it is a customer or shop cancelled order it might be clearer to have a CustomerOrderCancellation object, there could be other differences between customer or shop cancelled orders in future maybe.
This method returns the same thing as the Spree::Order#line_items_adjustments scope, but in a slightly less useful format (an array instead of a relation). The method's name is also totally inaccurate, as currently the only adjustments that appear on line items are tax adjustments for inclusive tax rates, which by definition have no effect on the price whatsoever...
This removes the following two deprecation warnings that we are getting
by millions (the two for each controller action test):
```
DEPRECATION WARNING: You are trying to generate the URL for a named route called "main_app" but no such route was found. In the future, this will result in an `ActionController::UrlGenerationError` exception. (called from process_action_with_route at /usr/
src/app/spec/support/controller_requests_helper.rb:49)
DEPRECATION WARNING: Passing the `use_route` option in functional tests are deprecated. Support for this option in the `process` method (and the related `get`, `head`, `post`, `patch`, `put` and `delete` helpers) will be removed in the next version without
replacement. Functional tests are essentially unit tests for controllers and they should not require knowledge to how the application's routes are configured. Instead, you should explicitly pass the appropiate params to the `process` method. Previously th
e engines guide also contained an incorrect example that recommended using this option to test an engine's controllers within the dummy application. That recommendation was incorrect and has since been corrected. Instead, you should override the `@routes`
variable in the test case with `Foo::Engine.routes`. See the updated engines guide for details. (called from process_action_with_route at /usr/src/app/spec/support/controller_requests_helper.rb:49)
```
It slows down our test suite and clutters the output a lot. As per my
investigation, this is something that arose in
https://github.com/rails/rails/pull/17453 and addressed in
https://github.com/rails/rails/pull/17725. TL;DR: Engines need to define
their routes in controller tests as shown in
https://github.com/discourse/discourse/pull/3011.
This, however, revealed a much complex reality in our case. We're still
using a `Spree::Core::Engine` with its own routes at
`Spree::Core::Engine.routes`. So we can't skip defining `routes { }` for
each of its controllers unless we merge this engine into our app, but
that's going to require more effort. What could that entail in
https://github.com/openfoodfoundation/openfoodnetwork/compare/master...coopdevs:move-users-to-app-routes.
To make it even worse, note that we override spree's core routes from
our own, resulting in a controller whose actions are being served from
routes defined in either `config/routes.rb` or `config/spree/routes.rb`
🙈.
When the user entered a number beyond the stock level, the browser was
correcting that to the max number which is very helpful. But Angular was
setting the model to undefined which removes the item from the cart.
Deactivating Angular's max behaviour let's us set the value ourselves
which is then used in the cart.
If the user entered an invalid quantity, Angular set the model to
undefined and we removed the input field to show the add button. That
makes it impossible for a user to see what the maximum quantity to enter
would be. For example:
- The variant has a stock level of 5.
- The user enters 7.
- Angular sets it to undefined.
- The input field disappears.
- The user is startled and doesn't know how to proceed.
But now we hide the input only if it's deliberately set to zero.
The user can now type anything into the quantity field and some of it
may not be valid. These safe guards ensure that the buttons still work
even if the quantity is undefined or out of range.
Angular guards against the value being out of range but that has other
side-effects. We want to be able to de-activate some of Angular's
behaviour.
