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

[mc12345678]

And each of those product's with attributes have variants that are combined so that a pair or combination of 3 attributes has one customid?

If so, the source of that issue starts in the method zen_get_customid in includes/classes/class.products_with_attributes_class_stock.php

I think I found the issue in line 284, still need to test the other methods of working with product, but when I changed the line from:

if ($customid->RecordCount() > 0) {

To:

if ($customid->RecordCount() > 1) {

Then only one appropriate customid was displayed on the shopping cart page...

[mc12345678]

And each of those product's with attributes have variants that are combined so that a pair or combination of 3 attributes has one customid?

If so, the source of that issue starts in the method zen_get_customid in includes/classes/class.products_with_attributes_class_stock.php

I think I found the issue in line 284, still need to test the other methods of working with product, but when I changed the line from:

if ($customid->RecordCount() > 0) {

To:

if ($customid->RecordCount() > 1) {

Then only one appropriate customid was displayed on the shopping cart page...

Although, the customid didn't replace the model number when that was set that way. Instead should be == 0 instead of > 1.

Yes, the result puts the customid in two places on the catalog side then, but that still is customizable on the template and perhaps more so in the software with further input. Trying not to make a mess of settings though.

[Dave224]

Yes, each variant consists of two attributes with a single customid. Option 1 (Scale) has three possible values; option 2 has two possible values. That's a total of six possible variants and each variant has a customid. What is perplexing to me is the different number of customid's displayed. That is, I ordered three of the six possible variants. One had the correct customid, another had two customids displayed, and another had four ids displayed.

I'll try your fix next.

[Dave224]

With your two changes described in posts 3089 and 3091 incorporated in the code, the correct customid is displayed on the catalog side on the shopping cart page, checkout confirmation page and orders history page. But the correct customid is displayed twice on the orders history page.

The correct customid is displayed in the admin on the orders page (edit or details) and on the packing slip. No repeats like on the catalog side/orders history page.

I tried it for each of the six variants of the product with two options, and on products with single options.

[mc12345678]

With your two changes described in posts 3089 and 3091 incorporated in the code, the correct customid is displayed on the catalog side on the shopping cart page, checkout confirmation page and orders history page. But the correct customid is displayed twice on the orders history page.

The correct customid is displayed in the admin on the orders page (edit or details) and on the packing slip. No repeats like on the catalog side/orders history page.

I tried it for each of the six variants of the product with two options, and on products with single options.

On the orders history page, with the doubling of the customid. Am I correct that in the stock configuration settings that customid is set to replace the model number?

One thing I hadn't yet worked on was a consistent way of presenting the customid. In some cases it is shown separate from the attribute's, some places along with, etc... in the account history it is both the customid and the products model which when replaced means that it shows twice... I can't use the current settings to identify whether both should be shown or not because that could change, I'm a smidge reluctant to add a field in the database to capture the condition at the time of recording, but guess that may need to be the way to go for appropriate handling. Alternatively could check to see if the two are the same and if so, only present one, but perhaps someone has a reason for both customid and model number to be the same and want both to be displayed/available...

Or perhaps modify how the products_model is "replaced" by the customid...

Regardless, thank you for the feedback and identification that when I changed the method verification of a variable's state in this area that I made a mistake.

[Dave224]

On the orders history page, with the doubling of the customid. Am I correct that in the stock configuration settings that customid is set to replace the model number?

Yes, I had that setting set to "1". Both customids were the correct SBA ids. Rerunning with the setting set to "false", I still got a double customid, one is the correct SBA customid. The other is the model.

BTW, I think you need to check the value of STOCK_SBA_DISPLAY_CUSTOM_ID in tpl_account_history_info_default.php. I changed line 44 to:

        <td class="accountProductDisplay"><?php echo  $order->products[$i]['name'] . ' ' . ((STOCK_SBA_DISPLAY_CUSTOMID == 'true') ? $customid[$i] : ''); // MOD for "Stock by Attributes" 1 of 1

As I mentioned in an earlier post, I normally run with customid turned off. My intention is not display custom id on the catalog side or in the admin with the attributes, but use the replace model with customid feature for admin orders-edit, invoice and packing slip pages to assist the packer. Also, I don't display model anywhere on the catalog side.

[jodean]

Can anyone explain why some of my Product_Attribute_Combo field records in Products_With_Attributes_Stock is Null on some records and Product_Id-Stock_Attributes ea 1025-2618,2622 on others?

Just want to understand if the field should be consistent for all records?

[mc12345678]

Can anyone explain why some of my Product_Attribute_Combo field records in Products_With_Attributes_Stock is Null on some records and Product_Id-Stock_Attributes ea 1025-2618,2622 on others?

Just want to understand if the field should be consistent for all records?

It is my understanding that at one point, that field was going to be used for some sort of cross reference/lookup operation; however, there does not appear to be anywhere in the code that retrieves that information. It just builds it on some initial variant insertion. The field doesn't appear to be needed; however, that aspect as introduced I believe by potteryhouse was not significantly discussed to explain the reasoning behind it. Mind you, its presence did help identify how to manage some of the data to further expand on the work done, but unless a functional need is identified, then might expect that this field and the code that accesses it will be removed in the future.

[bumba000]

Hello All,
Just wondering if there are plans to adapt this module to work in 1.5.6, or has that already happened and I just can't find the new version?

Thank You,
John

[mc12345678]

Hello All,
Just wondering if there are plans to adapt this module to work in 1.5.6, or has that already happened and I just can't find the new version?

Thank You,
John

Have you looked at: https://github.com/mc12345678/Stock_...butes_Combined

I haven't received any negative reports of its operation in ZC 1.5.6, though note that where a file is being merged with core files, that it is the changes supporting the plugin that are important and that the provided file may not be 100% up-to-date with the associated 1.5.6 version. That said, nothing has been seen that would directly affect the SBA code within that/those files.