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

[fbroz]

It is intended that out-of-stock (when displayed) be shown at the earliest selection point where such selection would result in any further selection to also be out-of-stock.

That said and seeing the indication of out-of-stock being displayed in the first dropdown, this would be a factor of the entry of data for the variants associated. Could you please identify the variant "arrangement" and quantity for each selection combination as well as the total quantity of stock identified to the main product?

Then may discuss settings, but let's start there first.

I believe this report from SBA will have the info you are thinking of, if not, please let me know what I can clarify:
hi-tec-c-stock-report.zip

[mc12345678]

Hmmm. Those setting look correct to support.
What about the dynamic dropdown settings and stock configuration settings?
(please *continue* to remember to *not* include the admin directory path)

[mc12345678]

Thanks mc12345678,



Thanks for the reminder, I have re-applied that change, and there may be a minor improvement there, hard to tell.



Thanks for that comment on the error, my template was calling that minimized jquery file and it seems to work just as well with an https:// call, so that seems to be corrected for the moment.



Regarding this feedback, I can share my personal thoughts at this point: I do see that it works correctly to populate the dropdowns with the correct attribute option names and values and allows customers to add the correct products to the cart. That is obviously the most important thing, and for me, the older sequenced_dropdowns in zc1.5.5e does not do this (no option values appear in the list, although the list seems to be the correct length). The "out of stock" or "backordered" functionality doesn't quite fit my purposes. In a sequenced list like mine, the option values from the first list in the sequence should not say "out of stock" unless all of the corresponding option values in the second list are out of stock. As it is now, all the option values from the first list (.25mm, .3mm, etc.) say they are out of stock. For my uses, only the second list needs to show out of stock notifications, really.



I did some more digging into this, and I think the log file does not exist because the slow query is not being triggered at the current threshold. I can look into this more in the future possibly.

Something else about this "current" result doesn't seem right. As far as could tell from the previous install, after the $backorder variable was set to false, out-of-stock notifications were not improperly presented...

I had been able to duplicate the problem of incorrect display of backorder on my test site and when $backorder was set to false, all other display appeared to work properly. I expected the same with the install performed there. If that wasn't the case, then some other recent change (for improvement) needs to be undone or corrected. Would appreciate notification of such issue.

[fbroz]

Hmmm. Those setting look correct to support.
What about the dynamic dropdown settings and stock configuration settings?
(please *continue* to remember to *not* include the admin directory path)

Here are those configurations for your consideration.

[fbroz]

Something else about this "current" result doesn't seem right. As far as could tell from the previous install, after the $backorder variable was set to false, out-of-stock notifications were not improperly presented...

I had been able to duplicate the problem of incorrect display of backorder on my test site and when $backorder was set to false, all other display appeared to work properly. I expected the same with the install performed there. If that wasn't the case, then some other recent change (for improvement) needs to be undone or corrected. Would appreciate notification of such issue.

I double checked that I made the correct modification based on your previous instructions, and I think this was the same behavior I was seeing before. If you think it would be worth trying a fresh install with just SBA merged, I could give that a try.

[mc12345678]

Those look correct. Ok. I'm going to have to take a step back and see if not having something in the new table is causing the issue observed, and if so then I have a way forward. My test site has at least one attribute identified as not stock dependent. That may be enough to cause a difference in operation. I'll have to see and correct that one way or another.

[mc12345678]

I double checked that I made the correct modification based on your previous instructions, and I think this was the same behavior I was seeing before. If you think it would be worth trying a fresh install with just SBA merged, I could give that a try.

Actually, could you try this to see if it works?

In tools->install sql patches

Enter the following:

INSERT  INTO products_with_attributes_stock_attributes_non_stock  (attribute_type, attribute_type_id, attribute_type_source_id) VALUES  ('PV', 3, 1278);

This will make the option value 3 (pink) a non-stocked dependent option for product 1278. Suggest then looking at 1278 and another SBA product to see if "issue" "resolved".

[fbroz]

Actually, could you try this to see if it works?

In tools->install sql patches

Enter the following:

INSERT  INTO products_with_attributes_stock_attributes_non_stock  (attribute_type, attribute_type_id, attribute_type_source_id) VALUES  ('PV', 3, 1278);

This will make the option value 3 (pink) a non-stocked dependent option for product 1278. Suggest then looking at 1278 and another SBA product to see if "issue" "resolved".

WOW! I feel like I just watched david blaine make the statue of liberty disappear!

This resolves the issue, even for SBA products that don't have pink as an option value! I don't understand how that works, but it does work in my use case.

[mc12345678]

WOW! I feel like I just watched david blaine make the statue of liberty disappear!

This resolves the issue, even for SBA products that don't have pink as an option value! I don't understand how that works, but it does work in my use case.

It's all because of how I mashed so much into the associated query. So either a "default" value will need to be added that has no stock effect on product, the query revised, or some additional logic to be sure that it all comes out like it should whether an option is stock dependent or not within the store.

Alright, could you try this to not affect your pink product but maybe offer continued operation like it is supposed to work?

update products_with_attributes_stock_attributes_non_stock  set attribute_type = 'TEST';

This should result in any/all entries in that table to be of a type outside the expected value(s) and help identify if it is a potential temporary fix or not and prevent overselling of product that are pink in that specific product. :)

[fbroz]

It's all because of how I mashed so much into the associated query. So either a "default" value will need to be added that has no stock effect on product, the query revised, or some additional logic to be sure that it all comes out like it should whether an option is stock dependent or not within the store.

Alright, could you try this to not affect your pink product but maybe offer continued operation like it is supposed to work?

update products_with_attributes_stock_attributes_non_stock  set attribute_type = 'TEST';

This should result in any/all entries in that table to be of a type outside the expected value(s) and help identify if it is a potential temporary fix or not and prevent overselling of product that are pink in that specific product. :)

I submitted this statement in the SQL Query Executor, and the products look good:

https://www.tokyopenshop.com/shop2/g...ec-c-p-18.html

Do I need to reverse the assignment of the pink option value to be a stock-dependent option for this test to be valid?