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

[dbltoe]

This was an upgrade from 1.5.5f(upgraded all the way from 1.2.7) to 1.5.7c. I do not know at what point SBA was originally added. Each product ID had more than one entry in the products_with_attributes_stock table. It is a warning and does NOT stop the shopper from purchasing the item.

We will just create a MySQL template to run in the admin each time one of these warnings comes up.

THANX for pointing me in the right direction.

[mc12345678]

This was an upgrade from 1.5.5f(upgraded all the way from 1.2.7) to 1.5.7c. I do not know at what point SBA was originally added. Each product ID had more than one entry in the products_with_attributes_stock table. It is a warning and does NOT stop the shopper from purchasing the item.

We will just create a MySQL template to run in the admin each time one of these warnings comes up.

THANX for pointing me in the right direction.

At that point in processing, the "limit" would be expected to be the number of product available as defined in the product information page, if the site was set to not allow "overselling". Because the product would not have any limiting defined attributes and it is permitted to be sold without attributes (basis of the product), then the prevention factor should become how the store handles the total quantity of product.

I'll also look at providing some sort of information in the admin screen for product found in the SBA table that are not otherwise expected to be displayed (effectively products_id in the SBA table where that product does not have attributes).

The logged message was coded in as a warning (instead of an error) because of the above expected path to completion and the possibility of that situation. Basically, there is information in a portion of the database (SBA table) that shouldn't be there which is made "noticeable" because there is not an excess check on the catalog side for "accuracy" of the admin controlled data. E.g., there isn't a check against the products_attributes table while a customer is navigating to see that the potential attributes tracked by SBA no longer exist on the product... If/When properly/sufficiently managed on the admin, that discrepancy should not exist. Unfortunately, at the moment there isn't a ready tool to identify the condition identified (product "had" attributes, but no longer does and in managing the attributes the downstream data was not sufficiently updated.)

Now, there is a check of attributes "fed" to SBA to see how they relate to the tracked product and is generally expected to reject options that do not exist (there is the potential for exceptions) or where stock is not permitted to be drawn (attribute selections result in negative stock where negative stock is not permitted). Again, a lot of caveats available/possible.

That code section may be a good place to incorporate a notifier to permit some other operation to be performed instead of just generating a log. Again, note that should not just simply delete the product from that table when coming across that log generating area, again because the "tracking" of a product being associated with SBA is currently tied to the session of the visitor with limited points at which that gets regenerated. Looking to revise this aspect, but need to be sure to capture the information needed in the cases where pages change.

[Dave224]

Can combinations of attributes be set up in SBA to track inventory but exclude other attributes? For example, I want to track inventory for each combination of shirt color and size, but not include another attribute which affects price, such as number of words printed on the shirt, since the words are printed after the sale.

I tried this on a sample product ignoring (not entering) the third attribute while setting up custom ids and inventory. But, although I can select the the first attribute while purchasing, the second and third attribute can not be selected. I'm using dynamic dropdowns. When I deleted the third attribute, everything worked with the two dropdowns.

If SBA can handle this case, how do I do it?

Thanks,

Dave

[mc12345678]

Can combinations of attributes be set up in SBA to track inventory but exclude other attributes? For example, I want to track inventory for each combination of shirt color and size, but not include another attribute which affects price, such as number of words printed on the shirt, since the words are printed after the sale.

I tried this on a sample product ignoring (not entering) the third attribute while setting up custom ids and inventory. But, although I can select the the first attribute while purchasing, the second and third attribute can not be selected. I'm using dynamic dropdowns. When I deleted the third attribute, everything worked with the two dropdowns.

If SBA can handle this case, how do I do it?

Thanks,

Dave

Yes, it is though at this time it is more via Install SQL Patches or phpMyAdmin than anything.

So there are some "hints" in the instructions in the configuration screen:

• To support the newly added non-stock table entry, follow the following guidance:
• A single product's value can be considered non-stock by entering the products_id as the source_id, the options_values_id as the type_id and the type as PV.
• A single product's options can be considered non-stock by entering the products_id as the source_id, the options_id as the type_id and the type as PO.
• A single option value (potentially applicable to all product) can be considered non-stock by entering 0 as the source_id, the options_values_id as the type_id and the type as AV.
• A single option (potentially applicable to all product) can be considered non-stock by entering 0 as the source_id, the options_id as the type_id and the type as AO.
• The expectation (upon software completion) is that an option_value will only be defined by only one of the above rules such that once all option values for an option name has been populated, then the option name itself will be defined and the individual records removed.

What does this mean? Well, there is a lengthy discussion of the "feature" that I again found by searching this forum on "gift wrap" which is along the lines of what this feature is considered. The ability to have something associated with the product that is not related to tracking the stock of the product.. The above "fields" are those that are in the table 'products_with_attributes_stock_attributes_non_stock'. The file 'includes\extra_configures\pwas_non_stock.php' contains CONSTANTS' and their associated definition which is expected to match to the database value(s).

I found that post #2811 contained a link back to where discussion centers on the feature asked about above. Obviously I suggest also looking around that post and the referenced post(s) as there may be further discussion around them that could offer some help.

Basically would need to identify how you plan on that particular attribute working throughout any Stock By Attributes relationship. In the case of text, yes it may be that you don't want to track the option name (option) for this one product, but may want to for another product... If it is for the one product, then would be considering the PO option above, if it is ever and always that it is desired to *NEVER* have it be related to stock then would consider the AO option. But remember if you pick a larger grouping, when it becomes desirable to then allow that specific characteristic either have to create a new attribute, find a way to exclude that product from the grouping or some other solution. Best to plan for your possibilities, understand the limitations, try to identify ways for things to be better and then implement whatever is needed.

I don't yet have a "visualization" of those options in the admin. I'm in the midst of some updates right now for the ZC 1.5.7 specific files which results in suggesting only two ZC 1.5.7 files need editing to support the full complement of features. Those two are admin/packingslip.php and includes/templates/YOUR_TEMP/templates/tpl_shopping_cart_default.php

Yes there are two files in the core includes directory that still need/could use modification, both are located in includes/templates/YOUR_TEMPLATE/templates and they are tpl_modules_attributes.php (which is edited primarily for dynamic dropdowns as they are not yet implemented as javascript/jQuery type objects) and tpl_modules_main_product_image.php to help enforce that the newly added id parameter though that might be possible through an observer when displaying the image... Likely will look into that so do not have to modify that template file either...

As to dynamic dropdowns, last I knew it works with this non-stock feature. I haven't tested it in a while but I would expect the above linked post(s) to provide information about it.

[mc12345678]

Just pushed a really big set of changes to github, though refrained from putting it on the master branch... For now...
It seems to be working for me in the many different testings that I've done, but, there are even many more differences out there...

So, biggest changes? (Possibly not yet incorporated into the admin installer "directions"), There are now only basically 3 files that get modified/overridden. They are:
1) includes/templates/YOUR_TEMPLATE/templates/tpl_shopping_cart_default.php
2) includes/templates/YOUR_TEMPLATE/templates/tpl_modules_attributes.php
and
3) admin/packingslip.php

Reasoning for each:
1) To support display of additional information offered by SBA to include the total quantity of a variant that exists, if stock is low, etc... Also includes modification to support display of customid information
2) Fully support the current rendition of Dynamic Dropdowns. There are other "tools" that could provide the display that this offers. More work needs to be done for either.
3) This incorporates a notifier that was added many years ago in support of a sort of picture display/swap plugin that was requested to be made compatible with SBA. The solution was to make SBA more compatible with that. As a result, this notifier has been retained.

What that also means though, is that if all of the current software is taken to a site, then the changes that were introduced into other template files and admin files from "previous" versions would need to be removed... NOTE the CHANGES need to be removed, NOT THE FILES (generally speaking)... These changes for the most part apply all the way back to ZC 1.5.1 (first tracked version for this plugin). I have attempted to remove the file(s) as appropriate from the distribution. That said, if you leave the changes in the template/admin files and navigate to an SBA product, then if the new method applies to your older version you will see that customid/model information twice...

I've kept the commit history of my changes. In some cases there was a progression from one style to another, in others I just make the full change at once. I have also gone and refactored a lot of the code to make reading it a little easier and to remove a lot of the if() { if() { if() { if() { if() {}}}}} type statements and similar things with loops where early exits are provided instead of large groupings of if statements that otherwise result in just moving to the next record.

I also transitioned many of the loops from for loops to foreach loops, in this way an interim item could be removed from the list and operation could continue without giving some sort of logged feedback that the item was missing or needing excess code to check for the presence/absence of the item.

I also addressed the issue that dbltoe brought up where now at the bottom of the screen there is a separate "listing" if product are identified in the product_with_attributes_stock table that currently do not have attributes assigned. The display appears similar to the current display when attributes are assigned. Could say it is still a work in progress, but basically if that problem does not exist, then the bottom of the screen from the viewer's perspective looks the same as it did. There is/will be a little extra html code, but....

Added an ignore statement associated with deleting product attributes to prevent operation from stopping/creating a mydebug file. I hadn't seen one, but the logic tells me that the ignore statement was needed.

Updated some of the catalog side observers to operate similar to their admin counterpart which has/had an effect on customid aspects.

Added observer files for customid display as well as image swap operation (this observer allowed removal of edits to the main_products_images file(s)). On image swap operation, I haven't tested the javascript/jQuery response when navigating to product not tracked by SBA where the attribute selection type is the newly added SBA simple select (dropdown).

One thing I did was to convert to using an array when requesting response from zen_get_products_stock or zen_check_stock where the array is made of the products_id and the attributes of the product. This information makes processing of the information easier than trying to possibly sort through the cart or an order, especially where processing of an order could change the attributes associated with the product. At any rate, this is to also replace a previous method that was used and is becoming more difficult to use as PHP versions go on. For the time being both methods remain available (sending as an array or overloading those two functions with the attributes information).

To see these new "features" can go to: mc12345678/Stock_By_Attributes_Combined at next-update (github.com)
or to see the differences to the current master: Comparing master...next-update · mc12345678/Stock_By_Attributes_Combined (github.com)

Haven't really looked forwards to some of the changes made here, because again, there has been code introduced to files since initial usage that no longer are considered necessary because I have found somewhere "convenient" to insert the value(s) sought... Doesn't mean it works great with *YOUR* store, but it is somewhere that works in a default store.

[Dave224]

I'm having trouble adding attribute combinations for a product. Everything was fine adding attribute combinations until I tried to add the 61st item for an item. There are two attributes: color and size for one product: tee shirts. When I submit the 61st item from the attribute selection, description, custom id and quantity input page, the green success message appears at the top of the page but the new item is not displayed on the product attribute list page and is not recorded in table products_with_attributes_stock. The highest stock_id for that table is 150. Have I hit a limit somewhere?
Dave
PHP 7.3, zc 157c, SBA version dated Mar 22, 2021 and downloaded from GIT

[mc12345678]

I'm having trouble adding attribute combinations for a product. Everything was fine adding attribute combinations until I tried to add the 61st item for an item. There are two attributes: color and size for one product: tee shirts. When I submit the 61st item from the attribute selection, description, custom id and quantity input page, the green success message appears at the top of the page but the new item is not displayed on the product attribute list page and is not recorded in table products_with_attributes_stock. The highest stock_id for that table is 150. Have I hit a limit somewhere?DavePHP 7.3, zc 157c, SBA version dated Mar 22, 2021 and downloaded from GIT

There is no programmed "maximum" number of variants that would limit the resulting number of variants. This could be "proven" by removing a variant and then attempting to add this "problem" variant. If still not successful, then its not the 61 variant issue, but instead a problem with the combination of the attributes. That said, the next thing is to try to identify the cause(s) of 1) the variant not being added, but a report of success...I haven't seen such a report in a possible long time. I thought I may have come across it several years ago, but...So, heres the things that would help to know about in no particular order:Attributes associated with the product as shown in the attributes controller, what option name types are associated (check box, dropdown, etc..)While I see that you are familiar with looking over the database, are equally familiar with reviewing the source page code of a web page? If so, please identify the value(s) for the dropdown option selections for these attributes that are being combined and any other dropdown selection values that would be expected to be submitted as part of generating this variant.Does this store support more than one language? (I don't know of a current issue with that, but have had to previously make some changes to support it.)Unfortunately also need to ask about the "history" of the store... is it an upgraded store (database is the item of interest/concern), from what if so, etc...I think from there, might have additional questions about the information that gets submitted, but a next consideration is identifying which of the processing paths are taken to reach the attempt to submit the variant, the data that is being fed to that insert method and then to chase down the processing of the data within that class method.Ultimately the "test" that is indicating a successful addition has multiple potential ways to support identifying success, so the condition(s) that are being met for that would be helpful but not by itself. Meaning, need to know some upstream info to likely be able to resolve this discrepancy. I'm all for solving it as it shouldn't be happening.

[Dave224]

mc12345678,
Here are some answers to your questions:
(1) Attributes associated with the product as shown in the attributes controller: color and size
(2) Option name types: both are radio buttons
(3) Values for the dropdown option selections for those attributes that are being combined: Ash, "Good for the Next 100 years!" and S (for small)
(4) Any other dropdown selection values that would be expected to be submitted as part of generating the variant: none if you mean other attributes for the variant that fails. Values for other variants include M,L,XL,2XL,3XL for size, and 11 other colors/descriptive info for color.
(5) More than one language: no, only english
(6) History of the store: fresh install of zc157c with SBA, Edit Orders, ZXPOS (purchased), ZCA Bootstrap Template (but not currently using), Better Together and other purchased SW Guy discount addons, and other custom tailoring. Database was copied over from v155f and updated via the zc v157c installer. Of note is that the SBA-related tables have a mix of products with and without a Unique Combo value. The product I am having trouble with has Unique Combo values for each variant.
(7) Processing path taken to reach the attempt: The success message displayed when adding the variant fails is "Product successfully updated" (PWA_UPDATE_SUCCESS). This is generated in only one place: in admin/products_with_attributes_stock.php. The browser URL (or URI?) is index.php?cmd=products_with_attributes_stock&action=add&products_id=706&search_o rder_by=p.products_model. The products_id is correct and I was trying to add a variant.
(8) Data fed to insert method: examining $saveResult when $messageStack is set to PWA_UPDATE_SUCCESS looks correct. sql_query is 'UPDATE products_with_attributes_stock set `quantity` = 10, `customid = 'ASH_GOOD_S', `title` = 'POS: Ash, Good..., S', `barcode` = null WHERE `products_id` = 706 AND `stock_attributes` = '163755,163806". Note that `barcode` is added as part of the ZXPOS add-on.
(9) Conditions that are being met to generate the success message: I developed a debug function that emails values of variables/expressions. See attachment.

Hope this helps,
Dave

debug_data.pdf

[mc12345678]

Very useful information, thank you. While each answer didn't necessarily provide the sought information, the other information filled in many of the gaps.

Ok, so a couple of things I see... The query: 'UPDATE products_with_attributes_stock set `quantity` = 10, `customid = 'ASH_GOOD_S', `title` = 'POS: Ash, Good..., S', `barcode` = null WHERE `products_id` = 706 AND `stock_attributes` = '163755,163806"
has a mistake in it, though I don't know if that was manually typed or copy/pasted. After `customid there should be another backquote (on US keyboard the key in the upper left corner in combination with the tilde (~).)

As far as uniqueness, based on what I'm seeing in admin/includes/classes/products_with_attributes_stock.php at/around line 716:

      $query = "SELECT count(*) AS total FROM " . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " WHERE (products_id = :products_id: AND stock_attributes = :stock_attributes:) " . (isset($productAttributeCombo) ? "OR product_attribute_combo = :product_attribute_combo: " : "") . (isset($customid) /* @TODO if customid is not required to be unique then and with a false */ ? "OR customid = :customid:" : "");

It appears that a duplicate/existing record is being found based on this query or the query as modified to support `barcode`.
The goal of this query is to use the provided information that determines if a lookup identifies a duplicate entry in the pwas table. Based on what happens next, it seems that there is a duplicate found. If the query is unmodified to support the additional field, then it would seem that the customid is non-unique. This is first based on the fact that it seems that the combination of products_id and stock_attributes being entered does not exist (report of variant not being in the list nor in the database) and that just before this call, the product_attribute_combo is generated to equal the combination of those two fields which since that original combination doesn't exist I wouldn't expect this one to exist either. Therefore, the only remaining "duplicate" is the customid of 'ASH_GOOD_S'. Please confirm that customid already exists in the database for any product. If it does not, please identify how this query is otherwise different than originally provided.

Then, if the customid actually is the duplicate record, then it would seem that the next "duplicate" searching query has not been updated to further reflect the comparison criteria or I have a problem with the evaluation that immediately follows. The words/concepts "seem" right, but the results don't seem to match. The query I'm speaking to is:

"SELECT count(*) as total FROM "  . TABLE_PRODUCTS_WITH_ATTRIBUTES_STOCK . " WHERE ((products_id = :products_id: AND stock_attributes = :stock_attributes:) " . (isset($productAttributeCombo) ? "OR product_attribute_combo = :product_attribute_combo: " : "") . ") AND `customid` != :customid:";
                  // If find a record, then the customid was assigned to some other product or the two parts of the where

As the logic is this: have already found that the earlier query identified one or more records searched on an 'or' basis. Because we are talking about whether the customid is unique or not, it could be that the customid is already assigned to this one product or it could have been used in multiple places... If it is already assigned to this one product, then it is fine that the customid "already" exists because the customid identifies to this product... But, if the customid is used elsewhere, then attempting to apply the customid to this record would mean that at least a duplicate exists, could be used more times than one. So... This query is expected to identify if the combination for this variant exists where the variant is not assigned to the current customid (with the customid not being empty)...

There may be an incorrect action after this for not finding a match, but I think at this point it would be good to get the results from above first... I know that I had made changes to the "duplicate" customid inspection some time ago with the possibility of not requiring a unique customid for all variants.

[Dave224]

There was a typo in the query.

The customid was used in another product. Changing the customid allowed the variant to be added. Thank you!!!

But I'm confused about what you said about the 2nd query. Is there something wrong with it? Seems to me that a failure or warning message should come up in this case. Is the integration with the barcode code faulty?

Dave
PS: I don't know why the attachment can't be opened.