-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use create_if_necessary instead of a simple find_or_initialize #3494
Changes from all commits
df95ee0
4bfe9a7
aa5eaab
7c79a1c
f40f627
d90be78
030bf6c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,7 +39,7 @@ def update | |
|
||
# Shows the current incomplete order from the session | ||
def edit | ||
@order = current_order || Spree::Order.incomplete.find_or_initialize_by(guest_token: cookies.signed[:guest_token]) | ||
@order = current_order(build_order_if_necessary: true) | ||
authorize! :read, @order, cookies.signed[:guest_token] | ||
associate_user | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great work, thank you!
That code was added in this commit spree/spree@a3d1f9a In that version when you call
P.S. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @bitberryru thanks for the analysis and the hint! So basically, if we inline # Shows the current incomplete order from the session
def edit
@order = current_order(build_order_if_necessary: true)
authorize! :read, @order, cookies.signed[:guest_token]
# vvv Inlined version of #associate_user
if try_spree_current_user && (@order.user.blank? || @order.email.blank?)
@order.associate_user!(try_spree_current_user)
end
if params[:id] && @order.number != params[:id]
flash[:error] = t('spree.cannot_edit_orders')
redirect_to cart_path
end
end The idea is that it's the responsibility of the authentication system to do the association in case the order was created before the login, and we can safely assume that we'll never encounter a persisted order that is authorized (via guest_token) and not already associated to the current user. Here's the solidus_auth_devise warden callback: # Merges users orders to their account after sign in and sign up.
Warden::Manager.after_set_user except: :fetch do |user, auth, _opts|
if auth.cookies.signed[:guest_token].present?
if user.is_a?(Spree::User)
Spree::Order.incomplete.where(guest_token: auth.cookies.signed[:guest_token], user_id: nil).each do |order|
order.associate_user!(user)
end
end
end
end About the checkout controller seems like the code is executed in a different sequence: class CheckoutController < Spree::StoreController
before_action :load_order # <<<< calls #current_order
around_action :lock_order
before_action :ensure_order_is_not_skipping_states
before_action :ensure_order_not_completed
before_action :ensure_checkout_allowed
before_action :ensure_sufficient_stock_lines
before_action :ensure_valid_state
before_action :associate_user # <<<< calls #associate_user
before_action :check_authorization # <<<< checks against the guest_token
before_action :apply_coupon_code I'd like to more research to be sure not to break something for some store… @kennyadsl @bitberryru what about dealing with removing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, another PR is perfect for this change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Moved the discussion in a separate issue: #3559 |
||
if params[:id] && @order.number != params[:id] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not evident to me why we need to include all these modules now, can you explain the reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously there was the FakesController class that was shared among all controller helpers spec files. During the file loading (but before the specs were ran) each helper was including itself into that class. So, at the time the specs were ready to run, the FakesController class had all the helpers included.
Now, instead, should be more clear on which helpers each helper depends, e.g. the
Order
helper needs methods fromStore
,Pricing
, andAuth
.