Stock by Attribute v4.0 addon for v1.3.5-1.3.9

mc12345678:

Yeah, you're the first one to report anything about it. Issues confirmed to exist and have been corrected through the following "comparison" commit (though this was discovered through use of EO 4.1.7 on ZC 1.5.5 that was slightly modified to work with SBA).

https://github.com/mc12345678/Stock_By_Attributes_Combined/compare/fa00792d8da3ca96da05aa62f6e221e299a2f0ae...02ef626fd13bdc37207af5e9633d1a60cda91485

These exist on the master branch of the plugin.

Hi again,

thank you for the answer. I applied all the changes, now no error log is generated but if i try to update and order containing an article with no SBA variants defined but with variants i get a warning and no update are made.
To be more specific i tested:

1. adding products with SBA variant -->work fine
2. adding products without any variants ---> work fine
3. adding products with variants no SBA defined --> work fine
4. modifing product with variants no SBA defined --> ERROR no update are made to just variants

To be precise now it show both the warning:

"Product 2 in the list below, named 'Incenso', with a quantity of 1 did not exist. Attribute(s) selected:
Quantita: 100
Its attribute(s) were not updated."

And after the green message: "Success: Order has been successfully updated."
The order has 2 article:
n°1 has SBA attributes and if I modify it, It got update correctly.
n°2 has no SBA attribute defined and if i try to update the attributes it wont, BUT if i modify quantity or price it work, so the only thing not updated are the attributes.

here a screen of it

Hope it will help

Info certainly did thank you for being so thorough. I haven't tested this, but would appreciate feedback on it.

In admin/includes/init_includes/init_eo_sba.php, line 171 add the following:

if (!$_SESSION['pwas_class2']->zen_product_is_sba($product_id)) continue;

                        $product_id = $old_product['id'];

                        if (!$_SESSION['pwas_class2']->zen_product_is_sba($product_id)) continue;
  
                        // Handle attributes
                        if(!empty($product_options) && is_array($product_options))

Thanks to you for your effort, I'm merely trying to solve this :D

Ok Modified and tested, the result is that now no warning appears and it correctly change the attributes. The problem is that it wont change the price associated with the attributes.

Let me be clear, in the image i posted You can see that the second products "Incenso" has a base price of 5 with a base attribute of 50g, the other attributes is 100g and should apply a +5.00 to the item (it does correctly during the normal buying process).
Now editing the orders wont show any warning and if You change the attribute it will be updated correctly, but the price will remain always 5.00.

I'm going to do some more testing with mixed product if i came up with something else i'll post it

Sorry i realize only after writing that probabily It's not something that concern SBA module but it's an Edit Order plugin problem cause it affect all the article (SBA or not).
I will test this to be sure.

Hi again,

confirmed everything works fine. Adding and removing articles and modifing it is ok!

Thanks a lot for the help

izar74:

Hi again,

confirmed everything works fine. Adding and removing articles and modifing it is ok!

Thanks a lot for the help

Thanks for the feedback. It has helped to make the plugin better. I can recall wanting to have those two changes in place, but had moved onto something else before either identifying the issue or it becoming a problem. I think I had just been merrily testing the SBA operation so much that I didn't go back to finish off the remaining. (think I even commented on its limitations at the time of posting awaiting some feedback that you have thankfully provided.)

Hi all,

I am new to 1.55e, just did a fresh install and i cant seems to find the option to display stock level on the attribute

Already did the options for
Config > Product type > General > Show Quantity in Stock = 1
Config > Stock > Show Quantity in Stock > true

Sync'ed a few times already but still not showing :(

Anyone could give me some tips on where should i start looking? Thank you!

thymine:

Hi all,

I am new to 1.55e, just did a fresh install and i cant seems to find the option to display stock level on the attribute

Already did the options for
Config > Product type > General > Show Quantity in Stock = 1
Config > Stock > Show Quantity in Stock > true

Sync'ed a few times already but still not showing :(

Anyone could give me some tips on where should i start looking? Thank you!
For single attribute product/option names like shown above, the option name type needs to be modified to the newly added (new to your ZC) SBA Basic select (dropdown) either through the option name manager or thanks to the support of fbroz through one of the two scripts in the configuration section.

If that has already been done, there should also be a setting in configuration->Stock: SBA Show Stock Level on Product Info Page which is really the option of concern because it operates independent of the display of the total product count.

mc12345678:

For single attribute product/option names like shown above, the option name type needs to be modified to the newly added (new to your ZC) SBA Basic select (dropdown) either through the option name manager or thanks to the support of fbroz through one of the two scripts in the configuration section.

If that has already been done, there should also be a setting in configuration->Stock: SBA Show Stock Level on Product Info Page which is really the option of concern because it operates independent of the display of the total product count.

Thank you MC, you solved my problem! Yes the SBA Basic select (dropdown)!!

This affects a "limited" group meeting the following conditions:

1. Software downloaded from the master branch of the github repository at https://github.com/mc12345678/Stock_By_Attributes_Combined
2. obtained between Jul 28th, 2017 and Oct 15th, 2017.
3. Product is tracked by SBA and has only one option name (attribute).
4. one or more option values (variant) is out-of-stock.

The condition observed is that when looking at the product info page, the list of attribute options contains some random like information such as the same option value listed more than once some with the out-of-stock notification some without, blank squares/selections, etc...

Specific resolution to this is to update the includes/classes/observers/class.products_with_attributes_stock.php file; however, there have also been some additional enhancements to the admin side. Basically the recommendation would be to update the includesand admin/includes files that are not template or version specific related.

The current commit leading to what would also be at the master thread right now is: https://github.com/mc12345678/Stock_By_Attributes_Combined/tree/7678a9c2619d85f70635c58bb09a50e8a56750f2.

I have downloaded the latest version and installed on a 1.5.5e store. I am having a problem with the display in the shopping cart. I checked in the shopping cart template file, but it has the right code. I can't understand why it's displaying the second "Out of Stock:" text when it should be showing "Available Stock:" with the available stock levels.

Also, that product has 1 in stock of size 6-12 month, and 2 in stock of size 12-18 months. The stock levels are synced in the admin. If I have 1 of the 6-12 and 1 or 2 of the size 12-18 in the cart, it displays fine. But if I try and do 3 of the 12-18, it is showing that the 6-12 are out of stock as well, even though there is only 1 of those in the cart, and there is 1 in stock.

Danielle:

I have downloaded the latest version and installed on a 1.5.5e store. I am having a problem with the display in the shopping cart. I checked in the shopping cart template file, but it has the right code. I can't understand why it's displaying the second "Out of Stock:" text when it should be showing "Available Stock:" with the available stock levels.

Also, that product has 1 in stock of size 6-12 month, and 2 in stock of size 12-18 months. The stock levels are synced in the admin. If I have 1 of the 6-12 and 1 or 2 of the size 12-18 in the cart, it displays fine. But if I try and do 3 of the 12-18, it is showing that the 6-12 are out of stock as well, even though there is only 1 of those in the cart, and there is 1 in stock.

I'm not yet able to reproduce the problem. I've tried two different product configurations. One where the product had multiple attributes and a group of attributes were assigned to offer a variant for each configuration. I've also gone to a product that had one attribute similar to the product in the image. I tried with mixed attributes as well as without and even applied a maximum number of product from which to select and was not able to reproduce the issue when the product quantity was synchronized with the number of product. Meaning if there were 2 size 12-18 and 1 of size 6-12 then the total quantity in stock for the product should be 3 as far as being synchronized. No matter how I approached modifying the quantity in the cart (modify on the shopping cart page or by trying to add from the product information page), I was always advised that the quantity was adjusted for the maximum quantity in stock and the value last modified was again updated to prevent exceeding either the total product in stock or the total for that attribute. I also repeated this by swapping the quantity available of the two attributes (in case there was some sort of sequence issue that was causing a problem) and didn't get a different result. Now I didn't try adding those product in reverse order, but...

Now... When I reduced the total quantity of the product to be less than the synchronized quantity (ie. in the above if the total product quantity were 3 and the quantity available of size 12-18 were increased to 3 (by attribute 4 available, but by product only 3), then I was able to get the error message that you describe as soon as I refreshed the cart where it already had quantity in it that exceeded the total quantity of the available product (I actually did quantities differently than provided above where I had 1 and 3 instead of 1 and 2, then my original total quantity was 4. When I had in cart 1 and 3 of the respective product, then reduced the total quantity available (simulating someone purchased a product but the individual attribute quantity hadn't been reduced) then I had an error message for both product (or any quantity product that had the same products_id basically) that the product was out-of-stock. If I reduced my quantity of 3 down to a quantity of 2, then the message disappeared, but if I then increased the quantity to 3 again, the error message again appeared.

So, it would seem to me that the issue is that at the time this occurs, there is a discrepancy between the sum of the quantity of attribute variants and the total product available such that the total quantity of product is less than the quantity for the applicable attribute product. As far as what to do in this situation, I'm certainly open to suggestions, I can tell you that there is a conflict in information at that point... What is the limiting factor? The quantity of attribute type product or the total quantity of product? How should the cart respond? If I'm allowed to pick X and Y items out of bag but the bag has some number less than the total of X and Y items, what should "auto" change the one that has the higher quantity, the one that was last modified (how can one tell which is last modified if both are modified on a single screen refresh)? Dump the changes made and just return back to whatever was last entered? (Think of having a long list of items, having determined just the right balance, selecting update cart and all the work done disappears? Not a good experience.) Should one reduce down to the lowest quantity permitted and then the other? Which one? "Higher quantity?" (What if both have the same quantity entered?) Last one added? Why should it get priority of reducing quantity?

Okay, anyways, open to suggestions and ideas, just know that there are more questions than answers in some cases.. Some would say why even allow that type of discrepancy to exist? Why not? Could work for some stores...

Now I didn't try with my store set to allow over-selling product, so that could be a condition you have set for yours, I don't know unless the settings associated with stock and SBA are shared.

Oh, I'm also going to compare my fileset to the github fileset which I presume you downloaded: https://github.com/mc12345678/Stock_By_Attributes_Combined as the source was not identified and some older versions certainly had issues.

Just did the following regarding file status:
retrieved the remote files from github to my local computer (no differences existed for my local github repository).
Reviewed where my local master pointer was at (one commit ahead as I was working on a feature for the admin menu), returned the pointer back one commit to where github was pointing and I did find one file that had a minor modification on my local computer as compared to github:
functions affected by the difference:
zen_get_customid
zen_get_sba_attribute_ids
zen_sba_has_text_field
zen_get_sba_attribute_info

The difference(s) are/were instead of simply checking if a value was empty, the value had to also be an array. This affected 5 lines of code.

I'm going to upload it in the event that it could be causing what was seen. The file affected is includes/classes/class.products_with_attributes_class_stock.php

After committing the above, I went through the tests again with the changes removed and didn't run into the described issue until again the total product quantity was less than the combination of attributes and the total in cart was more than the quantity that is entered on the product information page.

Be glad to fix something that I can make happen (and hasn't already been considered to remain as is for general use) and have a reasonable direction to take.

Hi there,

I appreciate your looking into this. However, I don't mean the error message above the cart, is that what you are referring to? I mean down below the product image, where it says "Out of Stock:". On the older versions, this would say "Stock Available:2". I've attached a screenshot of how it looks on the current site (SBA 1.5.3 running on Zen-Cart 1.5.1), as well as how it looks on the new site I'm working on (SBA 1.5.5 running on Zen-Cart 1.5.5e).

Additionally, on the older version, if there was too many of one product variant in the cart, that one would show out of stock, but if there was another variant of the product also in the cart with the correct quantity for the variant, it would show in stock. You can also see this in the screenshot.

It seems like the newer version is not treating each variant as having it's own stock. As soon as the total amount in stock is gone over, all variants show as out of stock in the cart, even though actually it's only the one variant that is over.

mc12345678:

I'm not yet able to reproduce the problem. I've tried two different product configurations. One where the product had multiple attributes and a group of attributes were assigned to offer a variant for each configuration. I've also gone to a product that had one attribute similar to the product in the image. I tried with mixed attributes as well as without and even applied a maximum number of product from which to select and was not able to reproduce the issue when the product quantity was synchronized with the number of product. Meaning if there were 2 size 12-18 and 1 of size 6-12 then the total quantity in stock for the product should be 3 as far as being synchronized. No matter how I approached modifying the quantity in the cart (modify on the shopping cart page or by trying to add from the product information page), I was always advised that the quantity was adjusted for the maximum quantity in stock and the value last modified was again updated to prevent exceeding either the total product in stock or the total for that attribute. I also repeated this by swapping the quantity available of the two attributes (in case there was some sort of sequence issue that was causing a problem) and didn't get a different result. Now I didn't try adding those product in reverse order, but...

Now... When I reduced the total quantity of the product to be less than the synchronized quantity (ie. in the above if the total product quantity were 3 and the quantity available of size 12-18 were increased to 3 (by attribute 4 available, but by product only 3), then I was able to get the error message that you describe as soon as I refreshed the cart where it already had quantity in it that exceeded the total quantity of the available product (I actually did quantities differently than provided above where I had 1 and 3 instead of 1 and 2, then my original total quantity was 4. When I had in cart 1 and 3 of the respective product, then reduced the total quantity available (simulating someone purchased a product but the individual attribute quantity hadn't been reduced) then I had an error message for both product (or any quantity product that had the same products_id basically) that the product was out-of-stock. If I reduced my quantity of 3 down to a quantity of 2, then the message disappeared, but if I then increased the quantity to 3 again, the error message again appeared.

So, it would seem to me that the issue is that at the time this occurs, there is a discrepancy between the sum of the quantity of attribute variants and the total product available such that the total quantity of product is less than the quantity for the applicable attribute product. As far as what to do in this situation, I'm certainly open to suggestions, I can tell you that there is a conflict in information at that point... What is the limiting factor? The quantity of attribute type product or the total quantity of product? How should the cart respond? If I'm allowed to pick X and Y items out of bag but the bag has some number less than the total of X and Y items, what should "auto" change the one that has the higher quantity, the one that was last modified (how can one tell which is last modified if both are modified on a single screen refresh)? Dump the changes made and just return back to whatever was last entered? (Think of having a long list of items, having determined just the right balance, selecting update cart and all the work done disappears? Not a good experience.) Should one reduce down to the lowest quantity permitted and then the other? Which one? "Higher quantity?" (What if both have the same quantity entered?) Last one added? Why should it get priority of reducing quantity?

Okay, anyways, open to suggestions and ideas, just know that there are more questions than answers in some cases.. Some would say why even allow that type of discrepancy to exist? Why not? Could work for some stores...

Now I didn't try with my store set to allow over-selling product, so that could be a condition you have set for yours, I don't know unless the settings associated with stock and SBA are shared.

Oh, I'm also going to compare my fileset to the github fileset which I presume you downloaded: https://github.com/mc12345678/Stock_By_Attributes_Combined as the source was not identified and some older versions certainly had issues.

Danielle:

Hi there,

I appreciate your looking into this. However, I don't mean the error message above the cart, is that what you are referring to? I mean down below the product image, where it says "Out of Stock:". On the older versions, this would say "Stock Available:2". I've attached a screenshot of how it looks on the current site (SBA 1.5.3 running on Zen-Cart 1.5.1), as well as how it looks on the new site I'm working on (SBA 1.5.5 running on Zen-Cart 1.5.5e).

Additionally, on the older version, if there was too many of one product variant in the cart, that one would show out of stock, but if there was another variant of the product also in the cart with the correct quantity for the variant, it would show in stock. You can also see this in the screenshot.

It seems like the newer version is not treating each variant as having it's own stock. As soon as the total amount in stock is gone over, all variants show as out of stock in the cart, even though actually it's only the one variant that is over.

So, I'm going to need more information. Do you have your store set to allow ordering in excess of what is available? Ie. What are the settings for like the first three options in configuration->stock? What about in the "old" store?

How is the product setup regarding min/max mixing? Do you have a maximum entered?

Mind you, again. SBA won't allow adding product to the cart in excess of what is available for the variant when all of the files from the recent version are put on the server and the store is not set to allow purchase when product is out-of-stock. Additionally, the ZC 1.5.5 shopping cart class has been updated to not allow a quantity to be in the cart greater than the available and will do so by reducing the item quantity to that which is in stock and provide a message about the change.

The fact that both product variants appeared to be out-of-stock is because the store does not allow over-selling, and the quantity of product available is less than the sum of the variant quantities associated with those in the cart. There is a setting that will allow the display of those quantities, but the display of the quantity available in stock won't happen if the store doesn't permit overselling and that both went out of stock is not because either variant ran out but the total supply did... that brings us back to one of the above long paragraphs. :)

Need actual setup information, verification that only the files provided in this version of SBA have been installed (not those from a previous version).

I can't reproduce the issue other than as described above. The additional discussion of other options and "activating" them depends on those settings and information.

I didn't test on a store that allows checkout when product is out-of-stock as that did not appear to be related based on the discussion of only having certain quantity available.

OK, it appears then that this version of the module just doesn't work the same in that regard. The total product quantity really shouldn't even matter when it comes to products with attribute stock. In the older version, if there are 3 total in stock, you could have 4 in your cart, but only the variant that is putting the stock overlimit would show as out of stock. There is no reason for both variants to show as out of stock. How then does the customer know which one to reduce? It's super confusing as it makes it look like they have too many of both variants, when actually they only have too many of the one variant. I think the old behavior is much more user-friendly and logical. I would change it back, but I'm really not sure how.

All settings are the same in both carts. The first three settings under Stock are all set to true.

What about the issue with it not showing the available stock in the cart?

mc12345678:

So, I'm going to need more information. Do you have your store set to allow ordering in excess of what is available? Ie. What are the settings for like the first three options in configuration->stock? What about in the "old" store?

How is the product setup regarding min/max mixing? Do you have a maximum entered?

Mind you, again. SBA won't allow adding product to the cart in excess of what is available for the variant when all of the files from the recent version are put on the server and the store is not set to allow purchase when product is out-of-stock. Additionally, the ZC 1.5.5 shopping cart class has been updated to not allow a quantity to be in the cart greater than the available and will do so by reducing the item quantity to that which is in stock and provide a message about the change.

The fact that both product variants appeared to be out-of-stock is because the store does not allow over-selling, and the quantity of product available is less than the sum of the variant quantities associated with those in the cart. There is a setting that will allow the display of those quantities, but the display of the quantity available in stock won't happen if the store doesn't permit overselling and that both went out of stock is not because either variant ran out but the total supply did... that brings us back to one of the above long paragraphs. :)

Need actual setup information, verification that only the files provided in this version of SBA have been installed (not those from a previous version).

I can't reproduce the issue other than as described above. The additional discussion of other options and "activating" them depends on those settings and information.

I didn't test on a store that allows checkout when product is out-of-stock as that did not appear to be related based on the discussion of only having certain quantity available.

I did notice that on the SBA setup page in the admin, it says that one of the changed core files is includes/modules/pages/shopping_cart/header_php.php, however, that file isn't in the github download. Are there just no changes to that file anymore?

Danielle:

I did notice that on the SBA setup page in the admin, it says that one of the changed core files is includes/modules/pages/shopping_cart/header_php.php, however, that file isn't in the github download. Are there just no changes to that file anymore?

I went through the commits and see that file was removed quite awhile ago...darn...a missing file would have been an easy fix ;)

Danielle:

I did notice that on the SBA setup page in the admin, it says that one of the changed core files is includes/modules/pages/shopping_cart/header_php.php, however, that file isn't in the github download. Are there just no changes to that file anymore?

Danielle:

I went through the commits and see that file was removed quite awhile ago...darn...a missing file would have been an easy fix ;)

Ok. So hope you haven't run off and tried to "restore" the modified shopping_cart header file. The problem will persist even so.

I found the issue and was able to reproduce it.

Line 948 of includes/classes/observers/class.products_with_attributes_stock.php

Change:

          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || $totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) {

To:

          if ($SBAqtyAvailable - $products[$i]['quantity'] < 0 || ($totalQtyAvailable - $_SESSION['cart']->in_cart_mixed($productArray[$i]['id']) < 0) && STOCK_ALLOW_CHECKOUT! !== 'true') {

That will resolve the marking of all product in the cart associated with the one products_id where the total quantity of the item's variants has exceeded the total available quantity of the item.

So, understand also that the concept of variant quantity and product quantity relates to some individuals conditions. Ie. Assume the shirts you sell are hand made/decorated. If you have 4 shirts, but enough product of one type to make 3 and enough product of another to make 2, well you only have 4 shirts. Which do you decide to not be able to make? Or do you let the purchase power of the customer figure it out for you by them buying what they want of what you have?

As to the other notification? Well, at one point around the same location in that file, the "feature" was basically disabled... seeing that someone wants it/likes it? I'll gladly put it back. I haven't looked for it recently and can't recall where I saw it, but at one point there was a lot of discussion that the maximum available quantity of a product shouldn't be made known... the store has been designed/redesigned to quite the contrary, so guess it was a false alarm...

The changes will be in that one file, so you don't have to do any sort of total reinstall. I have to figure out how to reinstate the remaining quantity and do so on something other than my cell phone. :)

Danielle:

I went through the commits and see that file was removed quite awhile ago...darn...a missing file would have been an easy fix ;)
The installer "information" does need to be updated. Last real modification to it was so that it would operate in a new install. Yes, there have been some changes to align more with ZC processes, but that identification is not applicable at least for ZC 1.5.5 where modifications have been pulled from the files.