Hi All,

I'm looking at Spree 2.1.0.beta (or spree-edge if you'd prefer) along with
a number of extensions. One extension that I'm looking at is the
spree_store_credits extension, which has a some specs that depend on the
spree.user.signup event. As part of getting the specs running clean for
this extension, I discovered a somewhat surprising change in behavior and I
wanted to understand i) if it was deliberate and ii) if so, what's the
motivation.

Specifically, I found that in order to get the spree.user.signup event to
fire it's not enough that the user signs up. The new user must enter the
checkout flow for the event to fire. If a user signs up, but never enters
the checkout flow during the lifetime of their first session, the actions
associated with spree.user.signup never get triggered. I confirmed this
via code inspection - the associate_user method is firing this event, and
that method is getting called as a filter on CheckoutController.

It looks like this didn't use to be the case, because the specs for the
spree_store_credits extension would never have passed if this had been the
case in earlier versions.

I'm assuming this change is deliberate, and I'm curious as to the
underlying reasoning. As a developer I found this surprising, and at a
minimum I'd have expected some documentation (I couldn't find any). Can
anyone shed some light on this decision?

Thanks.

Best,

Peter

Search Discussions

  • Ryan Bigg at Aug 28, 2013 at 4:49 am
    This change is indeed deliberate, in a way. It probably used to exist
    within spree_auth_devise and then was moved to CheckoutController for
    reasons that I don't know of.

    Is there somewhere else in particular that you'd prefer this event to be
    triggered?

    On Tue, Aug 20, 2013 at 10:48 AM, Peter Goldstein wrote:

    Hi All,

    I'm looking at Spree 2.1.0.beta (or spree-edge if you'd prefer) along with
    a number of extensions. One extension that I'm looking at is the
    spree_store_credits extension, which has a some specs that depend on the
    spree.user.signup event. As part of getting the specs running clean for
    this extension, I discovered a somewhat surprising change in behavior and I
    wanted to understand i) if it was deliberate and ii) if so, what's the
    motivation.

    Specifically, I found that in order to get the spree.user.signup event to
    fire it's not enough that the user signs up. The new user must enter the
    checkout flow for the event to fire. If a user signs up, but never enters
    the checkout flow during the lifetime of their first session, the actions
    associated with spree.user.signup never get triggered. I confirmed this
    via code inspection - the associate_user method is firing this event, and
    that method is getting called as a filter on CheckoutController.

    It looks like this didn't use to be the case, because the specs for the
    spree_store_credits extension would never have passed if this had been the
    case in earlier versions.

    I'm assuming this change is deliberate, and I'm curious as to the
    underlying reasoning. As a developer I found this surprising, and at a
    minimum I'd have expected some documentation (I couldn't find any). Can
    anyone shed some light on this decision?

    Thanks.

    Best,

    Peter


    --

    Ryan Bigg
    Community Manager
    Spree Commerce, Inc.
  • Peter Goldstein at Aug 28, 2013 at 11:55 pm
    Yes, which is why I described the behavior as surprising.

    My assumption (and I think the assumption of most developers/users) would
    be that a spree.user.signup event would fire when the user signs up - that
    is, upon creation of the user's account. As I described in my original
    post, that doesn't happen.

    Let me give you a hypothetical where this leads to what I consider
    counter-intuitive behavior, using spree_store_credits as an example.

    1. I advertise in my store that a user will receive $10 in store credit
    upon signing up, and I implement this by creating store credits on the
    spree.user.signup event
    2. A new user comes to my store, and signs up
    3. This user goes to their account page, which shows their store credit.
      At this time it will be $0, because they have not entered the checkout
    flow.

    If I were a customer of this site, I would think that I didn't get the
    credit that was promised - either because something is broken, or because
    the store owner is making a fraudulent promise. Not good.

    Now we can continue this scenario in a couple of ways. The first is the
    'success' case:

    4. The user adds an item to cart
    5. The user starts the checkout process
    6. When the user gets to the payment page they see that the credits are
    available and can be applied to their purchase

    So in this scenario, the messaging was off but the desired functionality
    still worked. Not ideal, but you can argue that it's acceptable. After
    all the customer got what they were expecting. And very possibly they'd
    never visit the account page before checking out, so step #3 never comes
    into play.

    But now consider a variation on this theme:

    4'. The user is interrupted, and needs to leave before completing a
    purchase or even adding an item to cart
    5'. The user comes back to the site from a different computer, or some time
    after their session expires
    6'. After logging in, the user's store credits still don't appear in their
    account
    7'. The user adds an item to cart
    8'. The user starts the checkout process
    9'. When the user gets to the payment page, there are no credits granted.
      The user never receives their $10 store credit

    The reason is pretty simple. The signup event is fired in this block:

               if session[:spree_user_signup] && @order
                 fire_event('spree.user.signup', user: try_spree_current_user,
    order: @order)
                 session[:spree_user_signup] = nil
               end

    Since session[:spree_user_signup] isn't true at this point (the user signed
    up in another session), this block in Spree::CheckoutController never
    executes.

    In my view this is strange behavior, both from the perspective of a store
    owner and developer (I'd expect this event to be fired on signup) and from
    the perspective of a customer of the store.

    Any thoughts?

    Thanks.

    --Peter



    On Tuesday, August 27, 2013 9:49:52 PM UTC-7, Ryan Bigg wrote:

    This change is indeed deliberate, in a way. It probably used to exist
    within spree_auth_devise and then was moved to CheckoutController for
    reasons that I don't know of.

    Is there somewhere else in particular that you'd prefer this event to be
    triggered?


    On Tue, Aug 20, 2013 at 10:48 AM, Peter Goldstein <peter.m....@gmail.com<javascript:>
    wrote:
    Hi All,

    I'm looking at Spree 2.1.0.beta (or spree-edge if you'd prefer) along
    with a number of extensions. One extension that I'm looking at is the
    spree_store_credits extension, which has a some specs that depend on the
    spree.user.signup event. As part of getting the specs running clean for
    this extension, I discovered a somewhat surprising change in behavior and I
    wanted to understand i) if it was deliberate and ii) if so, what's the
    motivation.

    Specifically, I found that in order to get the spree.user.signup event to
    fire it's not enough that the user signs up. The new user must enter the
    checkout flow for the event to fire. If a user signs up, but never enters
    the checkout flow during the lifetime of their first session, the actions
    associated with spree.user.signup never get triggered. I confirmed this
    via code inspection - the associate_user method is firing this event, and
    that method is getting called as a filter on CheckoutController.

    It looks like this didn't use to be the case, because the specs for the
    spree_store_credits extension would never have passed if this had been the
    case in earlier versions.

    I'm assuming this change is deliberate, and I'm curious as to the
    underlying reasoning. As a developer I found this surprising, and at a
    minimum I'd have expected some documentation (I couldn't find any). Can
    anyone shed some light on this decision?

    Thanks.

    Best,

    Peter


    --

    Ryan Bigg
    Community Manager
    Spree Commerce, Inc.
  • Ryan Bigg at Aug 30, 2013 at 5:23 am
    I have absolutely no idea how we could go about fixing this problem. Sign
    up is handled by the authentication extension, and so we have no other way
    of notifying Spree itself that a sign up event has taken place OTHER than
    setting a session variable.

    If you can think of a better way to do this, please submit a patch.

    On Thu, Aug 29, 2013 at 9:55 AM, Peter Goldstein wrote:

    Yes, which is why I described the behavior as surprising.

    My assumption (and I think the assumption of most developers/users) would
    be that a spree.user.signup event would fire when the user signs up - that
    is, upon creation of the user's account. As I described in my original
    post, that doesn't happen.

    Let me give you a hypothetical where this leads to what I consider
    counter-intuitive behavior, using spree_store_credits as an example.

    1. I advertise in my store that a user will receive $10 in store credit
    upon signing up, and I implement this by creating store credits on the
    spree.user.signup event
    2. A new user comes to my store, and signs up
    3. This user goes to their account page, which shows their store credit.
    At this time it will be $0, because they have not entered the checkout
    flow.

    If I were a customer of this site, I would think that I didn't get the
    credit that was promised - either because something is broken, or because
    the store owner is making a fraudulent promise. Not good.

    Now we can continue this scenario in a couple of ways. The first is the
    'success' case:

    4. The user adds an item to cart
    5. The user starts the checkout process
    6. When the user gets to the payment page they see that the credits are
    available and can be applied to their purchase

    So in this scenario, the messaging was off but the desired functionality
    still worked. Not ideal, but you can argue that it's acceptable. After
    all the customer got what they were expecting. And very possibly they'd
    never visit the account page before checking out, so step #3 never comes
    into play.

    But now consider a variation on this theme:

    4'. The user is interrupted, and needs to leave before completing a
    purchase or even adding an item to cart
    5'. The user comes back to the site from a different computer, or some
    time after their session expires
    6'. After logging in, the user's store credits still don't appear in their
    account
    7'. The user adds an item to cart
    8'. The user starts the checkout process
    9'. When the user gets to the payment page, there are no credits granted.
    The user never receives their $10 store credit

    The reason is pretty simple. The signup event is fired in this block:

    if session[:spree_user_signup] && @order
    fire_event('spree.user.signup', user: try_spree_current_user,
    order: @order)
    session[:spree_user_signup] = nil
    end

    Since session[:spree_user_signup] isn't true at this point (the user
    signed up in another session), this block in Spree::CheckoutController
    never executes.

    In my view this is strange behavior, both from the perspective of a store
    owner and developer (I'd expect this event to be fired on signup) and from
    the perspective of a customer of the store.

    Any thoughts?

    Thanks.

    --Peter



    On Tuesday, August 27, 2013 9:49:52 PM UTC-7, Ryan Bigg wrote:

    This change is indeed deliberate, in a way. It probably used to exist
    within spree_auth_devise and then was moved to CheckoutController for
    reasons that I don't know of.

    Is there somewhere else in particular that you'd prefer this event to be
    triggered?

    On Tue, Aug 20, 2013 at 10:48 AM, Peter Goldstein wrote:

    Hi All,

    I'm looking at Spree 2.1.0.beta (or spree-edge if you'd prefer) along
    with a number of extensions. One extension that I'm looking at is the
    spree_store_credits extension, which has a some specs that depend on the
    spree.user.signup event. As part of getting the specs running clean for
    this extension, I discovered a somewhat surprising change in behavior and I
    wanted to understand i) if it was deliberate and ii) if so, what's the
    motivation.

    Specifically, I found that in order to get the spree.user.signup event
    to fire it's not enough that the user signs up. The new user must enter
    the checkout flow for the event to fire. If a user signs up, but never
    enters the checkout flow during the lifetime of their first session, the
    actions associated with spree.user.signup never get triggered. I confirmed
    this via code inspection - the associate_user method is firing this event,
    and that method is getting called as a filter on CheckoutController.

    It looks like this didn't use to be the case, because the specs for the
    spree_store_credits extension would never have passed if this had been the
    case in earlier versions.

    I'm assuming this change is deliberate, and I'm curious as to the
    underlying reasoning. As a developer I found this surprising, and at a
    minimum I'd have expected some documentation (I couldn't find any). Can
    anyone shed some light on this decision?

    Thanks.

    Best,

    Peter


    --

    Ryan Bigg
    Community Manager
    Spree Commerce, Inc.

    --

    Ryan Bigg
    Community Manager
    Spree Commerce, Inc.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupspree-user @
categoriesrubyonrails
postedAug 20, '13 at 7:40a
activeAug 30, '13 at 5:23a
posts4
users2
websitespreecommerce.com
irc#RubyOnRails

2 users in discussion

Peter Goldstein: 2 posts Ryan Bigg: 2 posts

People

Translate

site design / logo © 2022 Grokbase