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

[mc12345678]

I want to thank the github user @jodeantn that pointed out an issue with the ZC 1.5.5 file(s) includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php and equivalently includes/templates/YOUR_CLASSIC_RESPONSIVE/templates/tpl_checkout_confirmation_default.php. Apparently when arriving at the checkout_confirmation page, an error was generated in the logs folder and the remainder of the page/final checkout was affected. Issue #43 at the github storage location provides some more detail. The error was similar to:

PHP Fatal error: Call to undefined method  payment::process_form_params() in public_html/includes/templates/YOUR_TEMPLATE/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() : ''));

Where YOUR_TEMPLATE would be expected to be the foldername for the active template for the user visiting.

The fix involves removing a portion of code that was incorporated into the SBA provision of the files for ZC 1.5.5 in December 2016, expecting that the PayPal InContext code provided/referenced in the solution would be used/considered. That appears to still be out for debate, but I didn't remove the following snippet until today about 15 minutes ago.

Applicable only to copies that were downloaded sometime between December 18, 2016 and today January 31, 2017:
To fix existing installations/downloads of the ZC 1.5.5 templates (although this code was not specifically marked as being applicable to SBA) then need to modify as applicable both
includes/templates/YOUR_TEMPLATE/templates/tpl_checkout_confirmation_default.php
and
includes/templates/YOUR_CLASSIC_RESPONSIVE/templates/tpl_checkout_confirmation_default.php

and change this: (portion to be removed in red color)

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() : ''));

to this:

echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"');

See issue #1192 on the ZC github for updates on incorporating the PayPal Incontext code that would be needed to support keeping the file(s) the way they were.

[ttfan]

I'm running SBA v1.5.4 with Zencart v1.5.5d with a Sheffield Blue template on PHP v5.4.45.
Although it seems to be working, when an order is placed, there is an intermittant problem in that the stock levels are not updated. I've tested it and it always seems to work, but when real orders some in, about 1 in 3 does not have the stock levels updated.

Any idea where to start looking?

[mc12345678]

I'm running SBA v1.5.4 with Zencart v1.5.5d with a Sheffield Blue template on PHP v5.4.45.
Although it seems to be working, when an order is placed, there is an intermittant problem in that the stock levels are not updated. I've tested it and it always seems to work, but when real orders some in, about 1 in 3 does not have the stock levels updated.

Any idea where to start looking?

Stock adjustment code resulting from a purchase is located in the includes/classes/order.php flowpath. SBA latches onto that operation using the observer class on the catalog side in includes/classes/observers. Next is the notifiers with the order class.

Could you please identify when the files were downloaded?

[mc12345678]

@ttfan,

Also, the product to which this is being reported against, how are it's variants populated? Is it product that has only one option name (one attribute) or product that has multiple option names (multiple attributes)? If multiple option names, is the stock populated such that each attribute has its own stock quantity or as a combined variant where a set of attributes each has its own quantity?

[ttfan]

Files were downloaded about 2 months ago, it was installed by Anne from Picaflor Azul.

Each product has one attribute,called "colour/thickness", and the options are for example "red 2.2mm", "black 2.0mm". There are different quantities for each of these options.
As I mentioned, when I test this, it seems to work properly, and the quantity (both the total and the particular attribute) is updated correctly, but it fails regularly for actual orders.

[mc12345678]

Files were downloaded about 2 months ago, it was installed by Anne from Picaflor Azul.

Each product has one attribute,called "colour/thickness", and the options are for example "red 2.2mm", "black 2.0mm". There are different quantities for each of these options.
As I mentioned, when I test this, it seems to work properly, and the quantity (both the total and the particular attribute) is updated correctly, but it fails regularly for actual orders.

Okay. I want to make sure that we are both talking about the same "setup" because each of the three "styles" of listing product as a variant has a different consideration and can take different paths in the code.
So, in the catalog option names area, you have one option name that is called colour/thickness. And when you go to the option values menu, in the dropdown to add a new option value you have a single selection in that list that reflects colour/thickness. And then for every possible combination of those you have an option value listing black 2.0mm, or red 2.2 mm.

Then in the attributes controller, you have one option name group of colour/thickness with all of these combinations listed as a single row for each combination.

Then in the products with attributes stock table under the catalog option, you have for a product that is to be tracked by stock again a single row for each combination and when you go to add variants for the product you have a single dropdown with text boxes below it. All correct so far?

And then you are able to adjust the quantity of the individual variants from the admin screen.

Now you are saying that when you try to make a purchase on your own, the quantities are being reduced, but somehow you are saying/identifying that when others are permitted access and make a purchase that the quantities are not reducing.

I'm curious about how you have identified the lack of reduction and if you can determine anything about what is going on at the store at the time when it seems like stock is not being reduced. I also question the date on which the software was obtained because there was some changes to the stock decrement portion that were made on Oct 11th because the code was not robustly considering all three of the above options. All three styles/methods were tested without issue, but it seems that somehow from the above that perhaps the testing was not robust enough to identify the issue(s) similar to what you are claiming.

So were there multiple people shopping at the time of the issue? Were they all working with the same product, did some of them have items stored in theirtfom a previous browse? Did they all submit their purchase at the same time?

All-in-all I might suggest placing the files that are in the base includes and admin folders over your existing version of those files and trying/seeing again how things go. Of course would rather have the new files compared against the old to see what has changed in the observer that might affect that operation, but seems better to get back on track and know that the recent files are in place rather than guess.

[mc12345678]

Trying to also see if there is a database cache issue, does it seem to relate to the number of SBA tracked items in the cart and/or the mix of those? (like all items of the same product but different attributes?) I plan on running some more tests but would like to try to target them as much as possible.

I continue to read through the code to see what issues seem likely/plausible.

[ttfan]

Thank you so much for looking into this. Sorry I've taken so long to reply, but I'm struggling to get my head around how this works, as I'm no programmer.

Okay. I want to make sure that we are both talking about the same "setup" because each of the three "styles" of listing product as a variant has a different consideration and can take different paths in the code.
So, in the catalog option names area, you have one option name that is called colour/thickness. And when you go to the option values menu, in the dropdown to add a new option value you have a single selection in that list that reflects colour/thickness. And then for every possible combination of those you have an option value listing black 2.0mm, or red 2.2 mm.

Then in the attributes controller, you have one option name group of colour/thickness with all of these combinations listed as a single row for each combination.

Then in the products with attributes stock table under the catalog option, you have for a product that is to be tracked by stock again a single row for each combination and when you go to add variants for the product you have a single dropdown with text boxes below it. All correct so far?

And then you are able to adjust the quantity of the individual variants from the admin screen.

Yes that is correct

Now you are saying that when you try to make a purchase on your own, the quantities are being reduced, but somehow you are saying/identifying that when others are permitted access and make a purchase that the quantities are not reducing.

I'm curious about how you have identified the lack of reduction and if you can determine anything about what is going on at the store at the time when it seems like stock is not being reduced. I also question the date on which the software was obtained because there was some changes to the stock decrement portion that were made on Oct 11th because the code was not robustly considering all three of the above options. All three styles/methods were tested without issue, but it seems that somehow from the above that perhaps the testing was not robust enough to identify the issue(s) similar to what you are claiming.

We don't have high volume sales, and although we have a large catalogue of item, we only have small quantities of each. We keep double records while we're testing, which is how we know it's failing regularly.

So were there multiple people shopping at the time of the issue? Were they all working with the same product, did some of them have items stored in theirtfom a previous browse? Did they all submit their purchase at the same time?

All-in-all I might suggest placing the files that are in the base includes and admin folders over your existing version of those files and trying/seeing again how things go. Of course would rather have the new files compared against the old to see what has changed in the observer that might affect that operation, but seems better to get back on track and know that the recent files are in place rather than guess.

It's highly unlikely multiple orders were placed at the same time, as out shop is low volume, and in most cases different items are purchased.

[mc12345678]

Thank you so much for looking into this. Sorry I've taken so long to reply, but I'm struggling to get my head around how this works, as I'm no programmer.


Yes that is correct


We don't have high volume sales, and although we have a large catalogue of item, we only have small quantities of each. We keep double records while we're testing, which is how we know it's failing regularly.


It's highly unlikely multiple orders were placed at the same time, as out shop is low volume, and in most cases different items are purchased.

All of the "consternation" is understandable. There's a lot of things that have to fall together to first even get results, then there are a number of twists and turns that could exist and explain why one feature or another doesn't work as expected.

From the description of the setup, right now I'm considering without additional "this is how I can make it happen again" data, that the issue is either out-dated code because there was a period around Oct 11th, 2016 when the stock decrement calculations/actions were changed with the expectation of handling the decrease of stock for any type of "allowed" variant combination. In your case, it appears that a variant is a single entry, no combinations with other things.

Couple of answers to questions can help resolve the issue, the first is to identify if the code contains expected information. If you could please access the file: includes/classes/observers/class.products_with_attributes_stock.php and then around line 442 possibly as far down as line 489, look for the function: updateNotifyOrderProcessingStockDecrementBegin.
If you could please copy the code of that function.
Then if you could reply to this message, select the # symbol in the message box toolbar to generate [CODE][/CODE] tags. The cursor should be between the two of those tags, and then paste the code.

So another question is how is the includes/classes/order.php file different from the standard/vanilla version of that file?

What other plugins are installed?

When looking at the product, purchases, type of product in the order(s), etc, what commonalities are found? Did the lack of decrease observed have anything to do with the remaining amount and the amount purchased? (ie. Was that the last available quantity and it didn't go out of stock, or any other information to help.)

Do the product have a maximum and is it limited by a mixture? Ie. Is there a case involved that limits the total quantity that can be purchase say to 5 and the customer can pick a total of 5 of the associated items, but only a total of 5, not 5 of each type of attribute? That type of thing.

Another relates (though I don't think it would be a specific reason for the issue) is the setting of using Dynamic Dropdowns, is it as most robust set to be active only when multiple attributes are involved?

[ttfan]

Here is the code you requested:

function updateNotifyOrderProcessingStockDecrementBegin(&$callingClass, $notifier, $paramsArray, &$stock_values, &$attribute_stock_left = 0){
    global $db; //, $pwas_class;

    $this->_stock_values = $stock_values;

    if ($this->_orderIsSBA && $stock_values->RecordCount() > 0) {
      // kuroi: Begin Stock by Attributes additions
      // added to update quantities of products with attributes
      // $stock_attributes_search = array();
      $attribute_stock_left = STOCK_REORDER_LEVEL + 1;  // kuroi: prevent false low stock triggers
      $this->_attribute_stock_left = $attribute_stock_left;

      // mc12345678 If the has attibutes then perform the following work.
      if(isset($this->_productI['attributes']) and sizeof($this->_productI['attributes']) > 0){
        // Need to identify which records in the PWAS table need to be updated to remove stock from
          // them.  Ie. provide a list of attributes and get a list of stock_ids from pwas.
          // Then process that list of stock_ids to decrement based on their impact on stock.  This
          // all should be a consistent application.
        // mc12345678 Identify a list of attributes associated with the product
        $stock_attributes_search = $_SESSION['pwas_class2']->zen_get_sba_stock_attribute(zen_get_prid($this->_productI['id']), $this->_productI['attributes'], 'order');
        $stock_attributes_search_new = $_SESSION['pwas_class2']->zen_get_sba_attribute_info($this->_productI['id'], $this->_productI['attributes'], 'order', 'ids');
          if (isset($stock_attributes_search_new) && $stock_attributes_search_new === false) {
              
          } elseif (isset($stock_attributes_search_new) && is_array($stock_attributes_search_new) && count($stock_attributes_search_new) == 0) {
              
          } elseif (isset($stock_attributes_search_new) && $stock_attributes_search_new && count($stock_attributes_search_new) > 0) {
              foreach ($stock_attributes_search_new as $stock_id) {
                  // @todo: address in PWAS table whether particular variant should be altered with stock quantities.
                  $get_quantity_query = 'SELECT quantity from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id=' . zen_get_prid($this->_productI['id']) . ' and stock_id=' . (int)$stock_id;
                  $attribute_stock_available = $db->Execute($get_quantity_query, false, false, 0, true);
                  if (true) { // Goal here is to identify if the particular attribute/stock item should be affected by a stock change.  If it is not, then this should be false or not performed.
                      $attribute_stock_left_test = $attribute_stock_available->fields['quantity'] - $this->_productI['qty'];
                      $attribute_update_query = 'UPDATE ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' SET quantity="'.$attribute_stock_left_test.'" where products_id=' . zen_get_prid($this->_productI['id']) . ' and stock_id=' . (int)$stock_id;
                      $db->Execute($attribute_update_query, false, false, 0, true);
                      if ($attribute_stock_left_test < $attribute_stock_left) {
                          $this->_attribute_stock_left = min($attribute_stock_left_test, $this->_attribute_stock_left);
                          $attribute_stock_left = $this->_attribute_stock_left;
                      }
                  }
              }
          }
          
/*        $get_quantity_query = 'select quantity from ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' where products_id="' . zen_get_prid($this->_productI['id']) . '" and stock_attributes="' . $stock_attributes_search . '"';
        $get_quantity = $_SESSION['pwas_class2']->zen_get_sba_attribute_info($this->_productI['id'], $this->_productI['attributes'], 'products', 'stock');
  
        // mc12345678 Identify the stock available from SBA.
        $attribute_stock_available = $db->Execute($get_quantity_query, false, false, 0, true);  
        // mc12345678 Identify the stock remaining for the overall stock by removing the number of the current product from the number available for the attributes_id. 
        $attribute_stock_left = *//*$attribute_stock_available->fields['quantity']*//* $get_quantity - $this->_productI['qty'];
  
        // mc12345678 Update the SBA table to reflect the stock remaining based on the above.
        $attribute_update_query = 'update ' . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . ' set quantity='.$attribute_stock_left.' where products_id="' . zen_get_prid($this->_productI['id']) . '" and stock_attributes="' . $stock_attributes_search . '"';
        $db->Execute($attribute_update_query, false, false, 0, true);  
        //$this->_attribute_stock_left = $attribute_stock_left;*/
      }
      $attribute_stock_left = $this->_attribute_stock_left;
    }
  }

  /*
   * Function that is activated when NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END is encountered as a notifier.
   */
  // Line 776
    /**
     * @param $callingClass
     * @param $notifier
     * @param $paramsArray
     */

Very few plugins are installed at this stage, as we're still trying to get things working. The plugins are: CK editor & image handler, as well as stock by attributes of course.

I can see no commonalities between orders that pass/fail, except that the ones fails always have the atrributes discussed above. Items with no attributes work properly.