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

[mc12345678]

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.

That appears to be the latest code which supports the rewritten stock decrement functionality for all three variant styles of:
1) One option name for a product with one option value per variant entry.
2) Multiple option names, each option name's value listed one time such that no two option values are combined in one entry.
3) Multiple option names with combinations of option values from different option names all entered in a single variant.

So, that said, I tried to look through the code to find something that might cause a spurious result and found two queries "buried" in the process that do not clear the query cache. Is that the cause? I don't know because haven't been able to repeat the issue and no further information has yet been provided/analyzed to be able to verify that the problem has been resolved. In fact, I'm not even sure that by making the changes (or not) if there is a way to validate that the problem has been solved, but anyways...

The suggested fix is available from: https://github.com/mc12345678/Stock_...3ab46ef5a4aa0e
and affects only one file in two places. The file is: includes/classes/class.products_with_attributes_class_stock.php

The lines affected are 416 and 1506 with the same fix applied to both of effectively adding to the query:

, false, false, 0, true

as can be seen at the above link.

Feedback would be appreciated.

[ttfan]

Thank you so much!

I have implemented the 2 changes. I've tested it myself, and it seems to work fine, so now I'll wait for the orders to come in, so that I can check it's all working. I'll report back here.

[mc12345678]

Thank you so much!

I have implemented the 2 changes. I've tested it myself, and it seems to work fine, so now I'll wait for the orders to come in, so that I can check it's all working. I'll report back here.

Would be interesting to see if it happens again, though by not knowing any information about how it occurred the first time(s) there's really little to be able to tell that the issue is resolved...

That said, the condition I could possibly see under the previous code and maybe causing the reported result is if a product was in the cart that was not tracked by SBA and after that a product was present that was tracked by SBA but caching recordered it "not" being SBA. The other is that data was returned for a different product and either no decrement occurred, or a different product's quantity was reduced.

Haven't yet been able to reproduce either situation but it is something conceptually possible if caching were the cause of the issue(s).

Look forward to results!

[ttfan]

Unfortunately it did not work. The very next order failed to update the quantity of the attribute, while the total quantity was reduced properly.

[ttfan]

I just had one thought though, it may not be related. When I test the module, I always use the 'bank deposit' payment option, as this goes straight through, and I don't have to make a dummy payment via paypal. However at least some of the orders that failed (possible all, I did not take note), were using payment via paypal. A Paypal payment forces the user to go to the paypal site to make the payment, then return to the shop to update the order and empty the cart. So perhaps this is where the attributes fails to update?

[mc12345678]

Unfortunately it did not work. The very next order failed to update the quantity of the attribute, while the total quantity was reduced properly.

Okay, so can you tell me about the order, the product and the particular setup?
Ie. How many products were in the order?
When thinking about the product from the perspective of SBA, which had attributes, what attribute(s), what type of attribute(s)?
In the pwas table under catalog, if you search for the products_id of the product in question, what are all of the variants (rows) listed for the product?
What was the quantity of each product ordered? How many were present before the order?
What are the settings for the product in relation to mixed quantity? Is there a maximum applied for the product?

Need details of how I can reproduce the issue so that I can fix the issue.

I don't need to know things like the products_description or what it does/is, just "data", sort orders, setup. If you can provide that, then perhaps I can repeat the situation.

BTW, any error logs in your logs directory possibly as a result of the purchase/sale?

[mc12345678]

I just had one thought though, it may not be related. When I test the module, I always use the 'bank deposit' payment option, as this goes straight through, and I don't have to make a dummy payment via paypal. However at least some of the orders that failed (possible all, I did not take note), were using payment via paypal. A Paypal payment forces the user to go to the paypal site to make the payment, then return to the shop to update the order and empty the cart. So perhaps this is where the attributes fails to update?

What method of PayPal is enabled?

Though that doesn't make sense either, because the only place that stock is reduced is through the includes/classes/order.php file which (should have) has the notifiers present to trigger the SBA decrement and if the total quantity went down, that should mean that the applicable SBA code would execute. But that said, I'll have to take a look at how session data is managed along that path, because currently the decrement code is session related and if in the process that is removed, then two things: 1) an error should be generated because the code can't be found, and 2) the stock wouldn't decrease. But, I thought that in previous review of what happens with the session, is that only PayPal and possibly cart related session data was modified. :/

[ttfan]

Here is one warning from the log file, the only one that seems related:
#1 trim() called at [/includes/functions/general.php:441]
#2 zen_not_null() called at [includes/classes/upload.php:61]
#3 upload->parse() called at [attributes_controller.php:310]

[08-Feb-2017 17:03:46 Australia/Sydney] PHP Warning: trim() expects parameter 1 to be string, object given in /includes/functions/general.php on line 441

I'm using the Paypal Website Payment Standard only.

[mc12345678]

Here is one warning from the log file, the only one that seems related:
#1 trim() called at [/includes/functions/general.php:441]
#2 zen_not_null() called at [includes/classes/upload.php:61]
#3 upload->parse() called at [attributes_controller.php:310]

[08-Feb-2017 17:03:46 Australia/Sydney] PHP Warning: trim() expects parameter 1 to be string, object given in /includes/functions/general.php on line 441

I'm using the Paypal Website Payment Standard only.

Okay, so with regards to using PayPal standard do you consistently receive the email from the store and PayPal with the full order being stored in the database, or do you find that you sometimes have to go back and request the purchaser to provide more information or any related issue(s)?

[ttfan]

Okay, so with regards to using PayPal standard do you consistently receive the email from the store and PayPal with the full order being stored in the database, or do you find that you sometimes have to go back and request the purchaser to provide more information or any related issue(s)?

Yes the full information is in the Paypal Email, including the attributes.
After looking at the orders over the last 24h, I can confirm that only the orders that were paid via paypal fail to update the attributes, the ones paid via other methods (none of which use an external website), all work properly.