behavior of allow_backorders option about spree HOT 11 CLOSED

On the admin side the allow_backorder is not honored either.
There non-available products should not even make it into the drop down list (a simple fix to the json function returning the list), but if more items are added than available, it should be caught, and a splash shown (not quite so simple, so I can't offer a complete solution).

from spree.

is this related to the possibility of adding more products to the cart than there're on_hand (with backorders disabled), or should that be a separate issue?
E.g. 2 items on hand, user adds one to cart, changes amount to 10 and updates cart -- and suddenly he orders 10 pcs of items we don't have on hand.

from spree.

same issue, once front end, once back.

If you want to split it, fine. It should have 2 test cases

from spree.

I'm working on it at the moment, I think I event found a Spree-way approach.
https://groups.google.com/d/msg/spree-user/FWQxXPMyLG0/czxdIZ-Z1YUJ

I'm in the process of exploring and experimenting intensively, but this stuff seems to work as expected (called from within SpreeSite::Engine.activate of course)

  ActiveSupport::Notifications.subscribe('spree.order.contents_changed') do |*args|
    event = ActiveSupport::Notifications::Event.new(*args)
    puts "caught event: #{event.inspect}"
    event.payload[:order].line_items.each do |line_item|
      puts "line item: quantity #{line_item.quantity}, in stock: #{line_item.variant.on_hand}"
      if(line_item.quantity > line_item.variant.on_hand) # can probably use also checking order state
        puts "OMG exceeded! limit it here"
      end
    end
  end

Feel free to join me for some real-time hacking, i'm tomash on Freenode and hanging at #spree at the moment

from spree.

yep, works like a charm. I've added the actual count updater and checking whether order is still within "cart" state (I don't want to limit myself while editing in admin panel -- even despite the fact that currently spree admin panel doesn't fire event spree.order.contents_changed when editing orders)

  ActiveSupport::Notifications.subscribe('spree.order.contents_changed') do |*args|
    event = ActiveSupport::Notifications::Event.new(*args)
    order = event.payload[:order]
    order.line_items.each do |line_item|
      if((order.state == "cart") && (line_item.quantity > line_item.variant.on_hand))
        line_item.update_attribute(:quantity, line_item.variant.on_hand)
      end
    end
  end

It could probably
a) use some test coverage (I'm working on it, i.e. setting up spree environment)
b) getting into spree-core

from spree.

c) some user interface

As a user I would be quite surprised (negatively) if I add 5 items to a cart, but less, possibly none, get added and I donÄt get any kind of feedback.

The other thing is, that it seems a rather convoluted way of doing things. I mean the event approach for just a straightforward if clause. Seems that it should just be hardcoded and return a true/false or item added. But then I am rather simple in approach. Don't see how you get the ui informed with this though.

from spree.

Yeah, I wanted to make it as non-invasive as possible, and using message passing seemed to be the cleanest approach (a lot safer than overwriting/monkeypatching). And yes, it's not the best interface-wise, but does the trick.

from spree.

First, well done on finding a novel solution to your problem. But I think this would be better solved with some plain old ActiveRecord validation (possibly on Order or LineItem)? That way the user could get some feedback, and it would be very testable?

from spree.

validation sounds nice, could mean extending existing models with just new calls without overriding existing ones.

from spree.

tomash are you working on a validation via the model ?

from spree.

I've been good with the notifications-based solution, but I hope this weekend I'll have a few hours for spree-core hacking!

from spree.