This changes how we display the description of weight, but it doesn't
change the `Spree::OptionValue`s that are being created when someone
adds a product to their cart.
This takes us closer by making the UI look more correct; but it feels
odd compared to settiong the `Spree::OptionValue` to the correct
unit on creation.
But on the other hand, that could possibly make things worse for the
shipping calculation bits.
See: https://community.openfoodnetwork.org/t/hubs-managers-can-choose-the-adapted-weight-and-measure-units-for-their-shops-given-their-own-local-situation/1289/11
We're not entirely sure what needs to be changed in order for this to
accurately work with shipping and other parts of the eCommerce platform.
We are assuming that so long as we canonically store the weight scale
in grams, that the shipping calculation will be able to do what it needs
to. So if we put in values for "oz" as grams, we may not need to do
much else in order to let product(s) be sold by the pound (or ounce).
Next steps appear to be:
- [ ] When looking at an order as a customer, do we want to show pounds
instead of grams? (See: http://localhost:3000/orders/R125684626)
- [ ] Compile a list of tests that are worth writing (because we have
no confidence that we know what we are supposed to be doing in
order for this feature to be "ready" to be used by people.)
- [ ] Write a test that demonstrates when we create a product with a
variant in pound that the product's shipping weight is correctly
calculated?
- [ ] Do we want to think about i18n?
Every page load creates a cart order if none is present. So when a user
logs in, they always have an order stored in their session. And
therefore, we never got to recover an old order.
We could have fixed the code to restore old orders. But as far as I can
tell, order recovery hasn't been working for years and I couldn't find
any issue requesting this feature.
If we wanted to implement order recovery, it should probably be designed
more carefully and included in the `current_order` method.
I was looking for library files that may be used but are not loaded.
I would then add the missing `require` statements. But I found that this
module isn't used any more.
Usage removed in:
310d1b3726
We used to delete old cart orders so that they wouldn't re-appear after
a successful checkout of another order. Keeping them ensures that we
don't remove an order that is still used by another device. It also
makes sure that we keep references of failed payments.
When we imported and merged Spree's controller modules with our
decorators, Rails started using Spree's original code again.
This was first included in v3.2.0 and deployed on 28 July 2020.
This Spree route conflicts with the one we define:
```
get "/login", to: redirect("/#/login")
```
for whatever reason there are 7 users that managed to hit the Spree one
instead of ours when confirming their signup email. It's not clear to me
though when this `/login?validation=confirmed` is really hit. The
confirmation email link passes a token in the query params and this is
not the case.
The idea is that `GET /login` makes the login modal to show up instead
of Devise's default behaviour (through inheritance) of showing a login
form page. OFN was never prepared to handle this as this bug proofs.
It adapts the method in ControllerHelpers::Auth to also use the after_login mechanism.
Ideally we would remove one of the two after_login mechanisms after_login and spree_user_return_to but they might still be in use.
