This was due to an incompatibility between two recent PRs: 5763 and
5733. PR 5733 did not take into account 5763 (the confirm email method was removed) and so the specs introduced
were broken.
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.
We didn't actually change any logic in our version of the Spree
environment file but if we do that in the future, we want to be sure
that it takes effect. Our file was ignored and not loaded before.
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.
Apparently, although we tend to add the type of spec file some RSpec
methods are not working without it. We're getting:
```
NoMethodError:
undefined method `helper' for RSpec::ExampleGroups::SpreeSharedOrderDetailsHtmlHaml:Class
```
```
NameError:
undefined local variable or method `controller' for #<RSpec::ExampleGroups::SpreeAdminUsersController::AuthorizeAdmin:0x00007fa8b32addf8>
# ./spec/controllers/spree/admin/users_controller_spec.rb:10:in `block (3 levels) in <top (required)>'
```
It needs more investigation but another day.
Spec files individually include the module and we specify the type of
spec in each RSpec's describe so none of this settings are needed. They
are just Spree's legacy I bet.
In this particular case, the user confirmations controller is redirecting to the reset password page but it doesnt know what is the raw reset_password_token
So we regenerate the reset password token so that it can know what's the raw value for the redirect
The method User#regenerate_reset_password_token is a proxy to the protected method in Devise::Recoverable
