Consider the following product:

product id 1
variation id 1 stock value 5
variation id 2 stock value 0

for the url /product/1?v=1 dumping the stock level in StockAvailabilityChecker::check finds 5.
for the url /product/1?v=2 it ALSO dumps 5, while the page shows a variation with stock of 0, and of course the add-to-cart button isn't disabled.

I assume that the same thing happens on the ajax call if you switch from variation 1 to 2 using the attribute select menu.

CommentFileSizeAuthor
#5 add_to_cart_availability_2847529_5.patch1.61 KBransomweaver
#3 add_to_cart_availability_2847529_3.patch1.46 KBransomweaver

Comments

ransomweaver created an issue. See original summary.

ransomweaver’s picture

ransomweaver commented
Issue summary: View changes
ransomweaver’s picture

ransomweaver commented
StatusFileSize
new add_to_cart_availability_2847529_3.patch1.46 KB

This code

$form_object = $form_state->getBuildInfo()['callback_object'];
$order_item = $form_object->getEntity();
$purchasable_entity = $order_item->getPurchasedEntity();

Is not providing an updated purchaseable_entity as the form is changed or if the variation is set using the query string. I can't find the proper variation anywhere.
There is a form_state storage 'selected_variation' which DOES have the id of the correct variation in it.

Attached is a patch that loads that variation. It could be improved by fixing to somehow not be specific to commerce_product_variation entity type. But then maybe if it wasn't a product_variation the storage var wouldn't be named selected_variation....

This patch isn't compatible with https://github.com/BBGuy/commerce_stock/pull/12 as it is against dev without that applied.

ransomweaver’s picture

ransomweaver commented
Status: Active » Needs review
ransomweaver’s picture

ransomweaver commented
StatusFileSize
new add_to_cart_availability_2847529_5.patch1.61 KB

Turns out that storage 'selected_varation' only appears if the order_item is rendered as the add-to-cart form and there are attributes to use to make select options from, so this patch needs to be more conservative and use the old way of getting the entity if this key doesn't exist in form_state storage.

steveoliver’s picture

steveoliver commented

@ransomweaver, good catch! If you open a PR for this, we can write and run new tests, and also you can cherry-pick commits from other dependent PRs for testing/development until those PRs are merged upstream (at which time you can rebase them back out).

guy_schneerson’s picture

guy_schneerson commented

Hi I am a bit confused on this one. I think I came across the same issue but not sure.

I am getting an issue where it looked like the AvailabilityManager was calling the StockAvailabilityChecker with the wrong product (default product) but turned out to be the cart form adding the wrong product this is on a commerce site with a closing product type with two attributes Size and color and looks like a commerce issue not a stock one (haven't hunted it in the issue q). Is this the same issue?
re: add-to-cart not disabled - Yes we need to do this but is that related to this issue?

ransomweaver’s picture

ransomweaver commented

@guy_schneerson, I don't see anything in the commerce issue queue. I will revisit this. I have a bunch of patches installed related to this issue: https://www.drupal.org/node/2707721
that affect add-to-cart, so maybe those are a) causing this problem or b) masking your problem for me.

ransomweaver’s picture

ransomweaver commented

This is now a PR https://github.com/BBGuy/commerce_stock/pull/37 and it requires drupalcommerce PR #593

guy_schneerson’s picture

guy_schneerson commented
Related issues: +#2918376: Implement commerce AvailabilityResponse
olafkarsten’s picture

olafkarsten commented
Priority: Normal » Major
Status: Needs review » Needs work
Related issues: -#2918376: Implement commerce AvailabilityResponse

Needs work because we don't get the expected interface changes in commerce core.

guy_schneerson’s picture

guy_schneerson commented
Related issues: +#2699611: [meta] Provide configurable stock transaction enforcement in UI
luksak’s picture

luksak
he/him
commented

@guy_schneerson could you tell me what is needed here so I can try to update the pull request?

guy_schneerson’s picture

guy_schneerson commented
Status: Needs work » Fixed

Thanks @Lukas von Blarer
This was an issue with the commerce core StockAvailabilityManager. We have implemented our own solution for the enforcement of the UI and I believe this is no longer an issue. I have tested it and found no issues.
If anyone finds any problems with this please open a new issue as this was specific to the StockAvailabilityManager that has been abandoned by the commerce guys at list for now.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.