This construct was previously used in Spree to switch out the user class with a dummy class during certain tests. We don't use this any more, so it's just mess.
🔥
This `session[:guest_token]` doesn't seem to ever be assigned anywhere in the codebase, and it doesn't seem to be read at any point either..? There are some various places where `current_order.token` is used and `session[:access_token]` is used, but not this.
As far as I can tell: it was part of an old version of Spree and related to the spree_auth_devise gem (which we no longer use).
This keeps the `OrderBalance` abstraction but removes the old code now
that the feature is enabled for all users in all instances and there are
no bugs reported. It's become dead code.
Instead of relying on Spree::Order#outstanding_balance we make us of the
result set `balance_value` computed column. So, we ask PostgreSQL to
compute it instead of Ruby and then serialize it from that computed
column. That's a bit faster to compute that way and let's reuse logic.
We hide this new implementation under this features' toggle so it's only
used when enabled. We want hit the old behaviour by default.
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.