mc12345678 / stock_by_attributes_combined Goto Github PK

As identified by soxophoneplayer in the zen-cart site: https://www.zen-cart.com/showthread.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1348275#post1348275

attempting to add a product that has attributes, is tracked by SBA, but without any attributes selected potentially causes an error log to be generated as seen in this list of "common" code:

        #1  products_with_attributes_class_stock->zen_get_sba_attribute_info() called at [root/includes/extra_cart_actions/stock_by_attributes.php:883]
        #2  include(root/includes/extra_cart_actions/stock_by_attributes.php) called at [root/includes/main_cart_actions.php:26]
        #3  require(root/includes/main_cart_actions.php) called at [root/includes/init_includes/init_cart_handler.php:44]
        #4  require(root/includes/init_includes/init_cart_handler.php) called at [root/includes/autoload_func.php:48]
        #5  require(root/includes/autoload_func.php) called at [root/includes/application_top.php:170]
        #6  require(root/includes/application_top.php) called at [root/index.php:26]

On the admin/products_with_attributes_stock.php, there is a dropdown "filter" that is sorted by products_model; however, other sort orders are possible to be programmed, but are not yet made accessible to users of the module. Need to add a sort of lookup filter option that can later be modified as well to suit individual needs, that when modified will affect the dropdown list. So either needs to do with javascript directly or by reloading the page with the new "configuration".

The default template file was changed in ZC 1.5.5. As a result this file should be in the ZC 1.5.5 folder instead of the main folder (unless the changes are to be applied to all versions to date). If to be placed in the ZC 1.5.5 folder, then the same file should be removed from the main directory and placed into its version specific folder. If to replace the previous version(s) then should not exist in both the main directory and the version directory. Replacement or not to replace depends on review of the changes and impact on previous versions.

When the page is loaded to display the SBA variants, nothing is assigned to have the focus, this could be improved by having the search field capture the focus and permit immediate search by text.

There are some actions that can be performed on multiple items at one time if the code would support it: ie. mass deletion based on marking the items to delete.

This feature would improve the user experience.

In the ZC forum, an individual identified that there was occasion for a product that had multiple option names (multiple attributes), that while using dynamic dropdowns would provide three on screen option names with the third reflecting one of the two previous option names. Dynamic Dropdowns were showing for the first two options, but the end result was to have three choices from which to select.

It is possible that the code (includes a series of inclusions) interfaces with a commonly named variable that is modified from the first point of assignment to the last point when evaluated and therefore is causing a separate set of code to be invoked and display additional option name selections. Local testing/data collection to that issue has not been performed to validate and therefore an attempt to rectify is being performed. Problem has not been otherwise reproducible. Not entirely sure what is causing it. It could be that the template includes some other action that causes this "duplication".

Ensure that if the setting for SBA is to show customid's that when a product doesn't have a customid that no additional content is displayed, or at the store owner's discretion that a specific statement is provided.

By providing a specific statement, testers of the plugin can validate the functionality/expected location of the customid information.

While a little late to the game on incorporating SBA into operation of the plugin Edit Orders and possibly Super Orders if necessary, it doesn't seem like it would take a great deal (famous last words) to add code that would support interface with Edit Orders I think once the aspect of the customid coming from the orders tables instead of the active store is worked.

Recently notified that the software would be better for admins if it would include some method of notification about a problem with storing a customid, particularly if the customid is a duplicate of an existing entry. Ideally this would notify that

1. the issue is that a duplicate customid was entered.
2. Which product shares the duplicate.
3. A means to modify the entered data so that it would remain available but editable.

Alternatively perhaps allow non-unique customid data, but if so doing, then need to provide a way to revert back to having unique only especially if a duplicate already exists during that time.

SBA install offers a javascript version of single dropdown boxes such that the box can be deactivated and show information a little differently; however, application of this functionality is frequently asked about. To improve on the process it is recommended that either:

1. the option name of a single attribute type be automatically applied when generating a variant for that product.
2. an option be provided for an option name when it is presented for generation of a variant on a single attribute product to offer/allow assigning the option name to the SBA version. Suggestion on this would be to identify if it was already assigned by another such variant and verification that it is still in use with this information presented to the store owner.
3. (less desirable at least in ZC 1.5.5 and below) is to have all such things applied against the default dropdown and not even have the additional dropdown option.

Options are available to disable product attributes when the existing quantity is 0 or negative and other factors are involved; however, an option is still considered available if the minimum quantity necessary to purchase a product is not available. For a customer, this would be discouraging because why show an available quantity that can not be purchased?

Ie. if the minimum quantity to purchase a product is 2 and the available quantity is 1, the product/attribute option appears to still be available. This occurs in both with PRODUCTS_OPTIONS_TYPE_SELECT_SBA and dynamic dropdowns. They require somewhat different resolutions; however, to achieve the same goal.

Some applicable code for the basic dropdown list is in: the function updateNotifyAttributesModuleDefaultSwitch within includes/classes/observers/class.products_with_attributes_stock.php.

Not sure at the moment of how ZC handles that with "normal" product of whether it waits until the product is attempted to be added to the cart or if up front it prevents attempting to add to the cart. The issue of units is also a part of this "concern". (Ie. minimum 2 units of 3 requires 3 to be added to the cart whereas a minimum of 3 and units of 2 requires 4 to be added to the cart.)

When inserting code into the admin/stock_by_attr_install.php file to permit ensuring that the database
was populated with the necessary configuration_key(s) to support dropdowns, the sql code that was inserted
was not modified to support installation into a database that used a prefix (DB_PREFIX). The code was a set
of simple queries against the configuration table using an update for one and insert ignore for others.

Ultimately the code would still run, but the problem would likely not be resolved if the applicable store
used a prefix.

Incorporating the php constant TABLE_CONFIGURATION in place of the sql statement of configuration will resolve this issue.

Just installed Stock By Attributes Combined for my 1.5.5 fresh install. So far everything works with one exception. The third checkout screen does not have button to proceed beyond Step 3 of 3 of the order checkout process.

Do you have any clues where I might have gone wrong in the installation?

I am getting the following error:
PHP Fatal error: Call to undefined method payment::process_form_params() in /home/tennes60/public_html/includes/templates/tennessee_traditional_flies/templates/tpl_checkout_confirmation_default.php on line 205

Line 205 echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"' . (is_array($payment_modules->modules) ? $payment_modules->process_form_params() : ''));

Url http://tennesseetraditionalflies.com/index.php?main_page=checkout_confirmation

This is coming from a fresh install Stock_By_Attributes_combined-master/1_5_5/includes/templates/YOUR_TEMPLATE/templates tpl_checkout_confirmation_default.php

I tried the Stock_By_Attributes_combined-master/1_5_3 and 1_5_4/includes/templates/YOUR_TEMPLATE/templates tpl_checkout_confirmation_default.php and it does not error.

However the 1_5_3 and 1_5_4 version is probably missing some 1_5_5 code?

Recently ran the Dynamic Dropdown javascript through an editor/checker of sorts (http://www.jslint.com) and found that there were numerous discrepancies identified. Some were just associated with code readability (3 spaces instead of 4, or positioned off to the right when should/could have been drawn in). Other issues were/could be more serious depending on the browser and its implementation of javascript. (Ie. a function used that is not declared until after the call to the function).

While the code has been functional in what appears most cases, it certainly needed some additional work and had not been touched from this perspective in a really long time.

This review and correction only covered the newly developed sba_sequenced_dropdown option that was specifically added to support multiple attributes and other future modifications. There was some base DD code that was also modified in support of providing corrections such as providing additional space when providing the stock object array, but other DD "styles" were not touched.

The results of this review/correction remain to be pushed to github, but will benefit the program greatly.

The new file provided in the title above probably ought to include some of the modifications made to the similar file elsewhere in the template structure (tpl_checkout_confirmation_default.php)

The header file of the checkout_shipping page was modified to provide a level of verification to ensure that the items in the cart are accurate to support checkout. At the time of development (ZC 1.5.1) adding this type of verification into the shopping_cart class seemed difficult and a few checks were added to the checkout_shipping page.

The main code is still there in the versions that follow, though more recent ZC versions where the notifier in the shopping cart class get_products function now includes passing the $check_for_valid_cart variable which means that the shopping cart class doesn't have to be overridden with a child class, but instead observers can now listen to/for the notification that the validity of the cart be checked. That said, either or both methods should be further integrated into SBA and the modification(s) to the header file should be removed so that SBA can become that much less intrusive. There are currently 8 files that are modified by the plugin spanning both admin and catalog side for ZC 1.5.5. I'm testing the removal of modification from the shopping_cart header page. Of the modifications made on the admin (4 files) the modification currently is mostly to add more interface selections to various pages (still a few more "plugs" to be added such as on the catalog listing of products in a category, and then from the SBA admin back to various applicable locations). At any rate, need to develop some "if this condition is met then the listing is obviously wrong" information. I've already built a bit of that into the add to cart portion of the operation, but haven't built much more beyond that down stream of the shopping cart.

Looking for "logic" criteria if anyone has any suggestions or ideas. There are not (yet) options to require a minimum or maximum of a particular variant of a product and a few other things that are checked in the current get_products function of the shoppingCart class, but no reason to not consider that future possibility in determining the in cart product are "real" product that can be verified as appropriate for checkout.

The current "sanitization" is if product can not be purchased while out of stock then to return the customer back to the shopping cart if the selection identifies that it is out-of-stock and also if attributes are not included in the particular product designation arriving at this page, then to see if the quantity requested (ie. page modified before submitting that removed the attributes, but kept the products_id and tried to add the product to the cart even though it is SBA but doesn't have attributes associated) exceeds the available quantity.

I have a Frankenversion of this plugin which I am attempting to reconcile to master. But right now I can't see where the various SBA defines (such as the define which indicates whether to show attribute images) are set. Please let me know where this is on the Zen menus and which PHP file creates it so I can start debugging.

The code currently will send out a low-stock notification in addition to whatever ZC has set if "after purchase", the variant quantity remaining is less than or equal to the ZC established STOCK_REORDER_LEVEL. It would/could be of benefit to add some additional admin controls related to specific variants and product.

To accomplish this, it seems that the admin menu would have to support additional fields, but there are some other things to be addressed with that menu option before additional fields could/should be added before it gets too complex to easily modify. Right now all of the modifiable fields are fairly hard coded where they could be made more flexible to a store owner's desires.

After adding some caching capability to improve the data collection rate, it seems that when adding product to the cart that there are warnings generated while evaluating the attributes.

The issue was brought up in the Zen Cart forum at the following post: https://www.zen-cart.com/showthread.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1349427#post1349427

The text option name has been added to SBA for processing; however, I am not yet sure that if marked as required that the system responds as expected, including required with other characteristics found in the option names manager. This needs to be tested/verified in order to close this issue.

Identified in the ZC repo pull #1377, there is information relating to the possibility of an improved process for instances/usage of list and each as quoted taken from DrByte:

An RFC for PHP 7.2 has been voted on for inclusion in PHP 7.2. It proposes to deprecate the each() function for PHP 7.2 and removes it in 8.0.

The each() function is exponentially slower and wastes resources vs foreach(), so we're refactoring it now whether PHP 7.2 finally does adopt it or not.

Things to note when refactoring:

1. foreach() doesn't need a reset() to be called before it runs, so those can be removed.
2. There are 3 syntax formats, depending on how the parameters are presented in the list() call:

a) while(list($key, $value) = each($foo))
This becomes foreach($foo as $key => $value)

b) while(list(, $value) = each($foo))
This becomes foreach($foo as $value)

c) while(list($key, ) = each($foo))
This becomes foreach($foo as $key => $value)

File(s) identified include but are not limited to (2/1/17):
admin/includes/classes/products_with_attributes_stock.php

When presented the list of SBA variants, clicking on an editable field should change from the present text to an editable field and the field should have the focus so that editing may immediately begin rather than waiting for a second click.

Currently the field becomes editable, but it requires a second click to make it active and receive text.

Condition:

• Cart is set to over-sell (STOCK_ALL_CHECKOUT = true) as found in the stock configuration menu.
• the product is set to have Product Qty Min/Unit Mix set to true, AND
• the variant quantity in the cart exceeds total stock quantity of the product.

When in this condition, the cart was causing all SBA product associated with that products_id to be identified as out-of-stock, even if the specific quantity for that variant had not been exceeded.

For a cart that has this set to false, then it is possible for the same condition to occur; however, logically if a cart is permitted to oversell, then notification to the customer of the out-of-stock condition should only occur where the store owner has set the limit (either at the variant level or the overall stock level) Those recently using the software would have been concerned with the overall stock level as that is what they became familiar with, previous users would be familiar with the individual product variant concern. So both concepts should remain available.

While trying to test modifications made to dynamic dropdown code, it quickly became apparent that the sequence of attributes in the admin when trying to populate a product did not make much sense in comparison to what was being displayed on the store front.

This realization identified the need to provide the options in a sequence that could/would make sense. As such it was determined that the sequence should be the same as provided to the customer for each product. Therefore the strategy used in the includes/modules/YOUR_TEMPLATE/attributes.php file was used relating to available attributes as assigned in the attributes controller. Further, the order presented is what is defined in the table products_attributes although this sequence could differ from a final desired sequence because within the attributes controller there is no independent control for the option name sequence. It is based on the value(s) assigned in the option name manager which could throw off desired sorted orders when attempting to present to the customer and to also minimize the number of option name/value pairs. Ie. ZC attribute handling of sequence requires some additional work; however, at the moment this is not a feature being attacked by this plugin.

Changes need to be uploaded to the master branch.

As identified by ZC cefyn at: https://www.zen-cart.com/showthread.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1330070#post1330070. The admin control file admin/products_with_attributes_stock.php along the path to uploading might be removed by server side action taken to review the code for potential security issues. Some suggestions were made, c

Need to modify shielding to acount for variousgaps

The admin/invoice file included in this package is not working 100% of the time. It is currently known that one of the differences in it as compared to how the other admin files operate is that the customid is collected differently than the others. This may be the central cause for the problems with the display of the information. It may be something else, but needs to be corrected at least for zc 1.5.5.

In ZC 1.5.5, includes/classes/ajax/zcAjaxPayment.php performs a stock check using zen_check_stock, but the function does not include the attributes as part of the stock check, therefore an SBA controlled product will not necessarily provide the correct stock information at this point of the process. So, this file/function would need to be touched in order to validate stock quantities. Unfortunately the data provided to the function at this point does not permit some form of independent review of the information to identify if the product is in stock or not without directly providing further information such as the product's attributes for that variant.

In pad_sba_sequenced_dropdowns.php the option name comments were added to the possible information to be displayed; however, in adding them, only the first comment was referenced. Detected by @scottcwilson, pull request #11 was created and is to be incorporated.

With an attribute set at zero quantity, it is still available on the product page. This is true whether Admin>Configure>Dynamic Drop Downs>Show Out of Stock Attributes is set to True or False.

When set to False, there is no indication the attribute is out of stock. However, it cannot be added to the shopping cart. Doing so results in an empty cart.

With ZC 1.5.4 and above, there has been functionality added to ZC to record the activity that has modified the DB. This, however, does not occur "automatically" and still requires the code to perform a logging action whenever it modifies the database (admin side). Unfortunately SBA progress has continued without incorporating that logging functionality which was recently realized when looking through core ZC code to support adding/using ZC code to further standardize operation and "protect" it for future upgrades.

There is code provided by lat9 in the ZC forum that offers backwards compatibility to allow the functionality to be called even though the "older" store will not actually log the operation. The same legacy code will be "ignored" in newer stores that actually do log the operation and thus this plugin can maintain its compatibility with slightly older stores "for now".

Hello,

In trying to get Stock by Attributes to work completely with a 1.5.6, I wanted to see if there will be a pure complete upload for 1.5.6 all in one place for upload. In a few cases the code that is removed/changed on Github does not reflect the current 1.5.6 code either because it was removed before the new released or mod removal (ie: my includes/functions/function_lookup does not reflect the same code removed/changed within the Github with no mods that adjusted the area)

Sorry if this is the wrong place I wanted to post this on Zen Cart forum but my user name has not been approved yet.

Some issues Im working around:

-Not sure if it should do this but out of stock attributes can be selected when "SBA Show Stock Level on Product Info Page" is set to false, but it does not allow checkout if the checkout/backorder option is turned off not sure if thats working as intended.

-Adversly Out of stock using SBA allows nothing to be selected at all in product info area when "SBA Show Stock Level on Product Info Page" is set to True. So if only size Small - color black shirt is out of stock and all the rest are available and have stock in SBA it will mark them all as "Out of Stock" disabling the product.

-Extra text showing up above checkout in the shopping cart area after updating from Github

My site is newer so its not impacting customers yet but thats why I wanted to take the time to drop a note. I think a pure 1.5.6a upload will likely fix my issues since I likely have code missing that should exist and code present that doesn't belong.

Thx in advance for all the work you do overall
RM

In previous versions of Stock By Attributes, the quantity of available stock when requesting more than what was either available in the store or in the variant offered information related to that quantity.
ie. Out-of-stock, low-stock with quantity, or quantity in general. This feature/information had been
disabled as a result of some alternate discussion/lack of direct interest expressed; however, recently as this version of the plugin was being installed by a previous user, the functionality was missed and desired.

Suggestion is to reinstate providing the data to support notification of the available stock and other related information.

Investigate the need for this file in this package.
By visual comparison using the comments applied in the SBA version of the file, the only changed information is at the end of the file and that information is captured when using ZC 1.5.5...

When working with product to which to add/modify attributes or quantity, sometimes identifying the correct product(s) can be difficult. A dropdown is currently available for listing all product that have attributes; however, additional help could be to add the category selector that is available in other areas of ZC such as the catalog menu or in the attribute controller. Selection from this list would/could narrow down the list of products presented for edit.

Need to evaluate what is/would be necessary to incorporate the use of this plugin: https://www.zen-cart.com/showthread.php?220678-Default-Attribute that adds the ability to select a product having a single attribute to the product listing (and not require navigating to the product info page first). It is currently applicable only to ZC 1.5.5+.

Consider/review the ability to use the notifiers within the shopping_cart class instead of the extra_cart_actions folder for working with SBA product.

Reviewing the original code provided for export of the SBA datatable, it appears that the condition of multiple attributes applied to a product is not sufficiently covered in the export data to then turn around and support import. For product that have a single attribute, this feature appears to work fine though some data is modified (quotes removed, commas removed, etc...) and provides a file that can then be imported. In the routine there is also a little extra work that can be done to improve on compatibility with say UTF-8 and alternate languages, but that is something that can be addressed along the way.

When looking at the Products With Attributes Stock (SBA) admin menu, there is an option to synchronize the total quantity of product with the individual quantities of variants. One purpose that is currently included in the code for this is to identify the total number of product that could exist/be purchased if someone were to select/add all variants to their cart and in particular if the total number of purchased items is controlled by max and mixed product. With a product (not an SBA variant) marked at mixed and a maximum applied, then only the quantity of product identified by the max using any variant can be added to the cart (assuming also that can not checkout if stock is 0 or negative).

Consider the following condition:
Max of a product is 8.
It comes in 4 variants
v1 - 2 products avail
v2 - 10 avail
v3 - 10 avail
v4 - 4 avail

Cart is setup to not allow "negative" quantity of product.
If the total available quantity is not sufficiently high enough then conflicts occur with adding the product to the cart and calculations. The current product quantity entry does not automatically update the total quantity of product (though I guess a switch could be added to support that), but I was thinking that perhaps some color indicators would be worth adding in the event that the total quantity of stock isn't actually the sum of the individual attributes but instead a smaller quantity. (I thought that there was such a test in the processing of product to prevent adding an individual variant that exceeds the total quantity provided on the product info page.)

Anyways, I have also identified what appears to be a bug with ZC shopping_cart refreshing (updating) by selecting the update/circle button while viewing the shopping cart. The ZC thread on this topic.

It would be really cool if it was possible to set a price for a given set of attributes, just like the model number and stock.
Needing this for a new project (and while Bundled products is still not operational). I am going to look into the possibilities and if it is doable.

Currently, the way that Dynamic dropdowns is incorporated into ZC (permitting display and handling of multiple attributes) is to have DD insert the text for the first dropdown and then calculate the text of remaining options throughout. The result of this is that if a customer has disabled javascript for some reason (or possibly a javascript error on the page preventing further execution) that after making the first of many selections, no other selection is made available. Therefore, the product can not be fully defined and added to the cart.

What needs to happen is that DD supplements the existing page such that the features added by it become available if the page verifies satisfactory. The attributes file now offers a hook to which DD can attach and build the necessary inner workings for each option. That way, base ZC can build an expected set of attributes and the product can be selected without the extra information, but upon submission is verified and notice given of any issues or if javascript is enabled and all is working as expected, then the limiting features of DD will help the customer with selection and eventually allow adding a product that is fully defined.

To make this fully robust, some additional javascript is necessary to build each option type so that it can be properly controlled during entry.

I've upgraded a site from ZC 1.5.4 to 1.5.5 and SBA. The site only uses a single attribute per product. When I change the Option Type from Dropdown to SBA Select List (Dropdown) Basic, the attribute no longer displays. No error log. I've double checked the installation.

• Admin>Dynamic Drop Downs has been left at the default settings.
• SBA>File Check reports no errors [other than previously noted false positive of /includes/modules/pages/checkout_success/header_php_sba.php]

Do I need to do something other than change the Option Type?

When left as Dropdown the only issue is that an out of stock attribute is not marked as such. The rest of the functionality seems to be just fine.

I just upgraded to ZenCart 1.5.6. I used Stock_By_Attributes_Combined in my 1.5.5 ZenCart version. I do not see any installation instructions in the download. Are installation instructions available.

Have recently used Dynamic Price Updater along with SBA; however, it required some modification in order to not replace the applicable onChange event(s) assigned to the attribute selectors... See DPU sets the applicable event to whatever DPU needs in order to update the price. This is instead of listening to the handler and performing the action that is expected/necessary in addition to whatever other JS is in place. Perhaps if other JS is loaded ahead of DPU it would fire properly, but it doesn't exactly seem that way. Once the applicable element.event was modified to addEventListener the DPU code worked as well as Dynamic Dropdowns... There are or may be other localized modifications necessary as outlined in the DPU forum; however, this characteristic had not been found and was a deterrent to using DPU.

When the option name type is chosen to use SBA Select List (Dropdown) Basic, then if the option value contains specific html entities (ie. British Pound as the currency symbol £), then the ampersand & is further sanitized and the result is that the text version of the html entity is presented to the user rather than the html for it.

This is caused by some over sanitization that was applied in includes/classes/class.products_with_attributes_class_stock.php in the function zen_draw_pull_down_menu_SBAmod. The sanitization uses zen_output_string_protected which will convert the ampersand of £ to the html entity & resulting in £ to be presented to the browser to appear as £ instead of £.

Use of previous code (commented out at or about line 192) would restore functionality, though as written would not convert the simple use of & to the html entity &. To properly/fully support its presence, at least two conditions could be used within that zen_output_string function recommended at least with option 1 first:

1. a space before and after & converted to the html entity with a space before and after it, and
2. a space after & converted to the html entity with a space after.

Any additional "variation" (ie. a space before) would require something more like can be gained through using Regex or identification that the & is only in the last character of the string.

Other alternatives of keeping the existing oversanitization would be to then replace applicable overly sanitized sections with the desired content using some known/expected data. I.e. usage of the data from CURRENCIES_TRANSLATIONS to oversanitize the keys and substitute the corresponding value. This particular process of course may not correct all cases of oversanitization.

Back in June when a single class was assigned to be used from the base instead of redeclaring the class on an as needed basis and potentially make individual errors, a single error was made related to the packing slip but at or near the same time that issue #31 became a problem.

The correct class declared as a variable $products_with_attributes_stock_class was pulled into the function for the notifier: NOTIFY_PACKINGSLIP_IN_ATTRIB_LOOP (function updateNotifyPackingslipInAttribLoop), but then later it was referenced as: $products_with_attributes_**with_**stock_class.

The query that was added to the install section of the plugin to remove readonly attributes from variants appears to reconstruct the resulting variant incorrectly. This should be reviewed and then possibly options provided on what the user desires to happen as there are possible different "solutions" and ideally they be chosen from a convenient location. Ideally, the install script might be modified to not have all options in just the upper dropdown, but need to work through the issues.

As of Zen Cart 1.5.6, a notifier has been added to includes/functions/functions_lookup.php negating the need to modify the file; however, to properly observe this operation, the observer needs to load before any applicable use of the notifier. At this time the first trigger point at which this observer must be used appears to be at the point where includes/init_includes/init_cart_actions.php is loaded. It is during this process that the requested quantity to add or modify is evaluated against the quantities in the cart and the available quantity. If the observer is loaded after this operation, then it does not interact and report the specific quantity.

In Zen Cart 1.5.6, the trigger point for includes/init_includes/init_cart_actions.php is 140. Changing the load point for the necessary software to 135 will ensure loading before execution.

A user of SBA had setup product to have one option name with multiple check boxes (option values), when selecting add to cart with 2 or more checkboxes selected, SBA processing could not complete because the option values were turned into an array that was not properly handled.

While the application of the checkboxes was not as one might suggest, the operation of the software none-the-less was wrong. Need to be able to handle/address checkboxes in quantities/combinations? This may present a problem in stock control, but will see what can be done with it.

Historically, when showing options of the dynamic dropdown code, out-of-stock options were not presented. These items would be identified as out-of-stock if they were not populated in the SBA database table (PWAS) or if the quantity was <= 0. When out-of-stock quantities were made available for presentation, then all possible combinations based on the entries made in the attributes controller were added/presented. If the combination did not exist then it was marked as out-of-stock; however, there was a possibility that such product could never be put back into stock because they may never exist in such a configuration.

This has been resolved with consideration of an admin switch to allow either configuration to be presented. The files remain to be uploaded to the master branch, but testing so far has been promising.

Now, with this option enabled, product that have been identified in the database as "out-of-stock" will display when presenting out-of-stock product, but those combinations that would not exist because they are not populated in the database will not show on that same list.

Ie: attrib1-value1
attrib2-value3 qty 1

attrib1-value2
attrib2-value3 qty 0

attrib1-value2
attrib2-value4 qty 5

where attrib1 has values 1 and 2, attrib2 has values 3, 4, and 5 assigned in the attribute controller.

Then display of the product will only show the combinations of the above 2 and not a combination that includes attrib2-value5 because it is not assigned. As well, attrib1-value1, attrib2-value4 will not be displayed. attrib1-value2, attrib2-value3 will be displayed as out-of-stock.

This was initially addressed/discussed at: potteryhouse/stock_by_attribute_1.5.4#26

However is resolved here so will be closing out that item.

It seems like based on the check in includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php
you only display images for non-sba products.