This Stripe-payment-authorizing logic is used by backoffice and subscriptions orders (but not the checkout), and was previously being handled by the #show action in Spree::OrdersController. It involves the user being redirected back to OFN after visiting a Stripe URL.
StripeConnect has been replaced by StripeSCA but some people still use
the old StripeConnect. Let's prevent people from creating deprecated
payment methods before migrating existing data.
params[:token] and session[:access_token] are only really used in the context of guest users in the customer-facing parts of the app. Here the user should be fully authenticated already to view the page. There aren't any URL that point at this controller which append a token to the params.
There are 4 or 5 different places in the app where we reference a :token and params[:token] for completely different purposes (they're not even vaguely the *same* token).
This is an attempt to clarify the places in the app where we use params[:token] in relation to *orders*, for allowing guest users (who are not logged in) to view details of an order they have placed (like after checkout completion), and differentiate it from the various other places where params[:token] can actually be used for something entirely different!
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).
But let people include out of stock variants by checking a checkbox if they want.
Note, we only apply the variants in stock scope if a distributor is
present. I think this is because this search method is also used when
setting up subscriptions so I don't think we want to change the
behaviour there.
Co-authored-by: Maikel Linke <maikel@email.org.au>
