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

jeking:

I do think you understood the question correctly.

Ultimately either out of stock or not displaying any unavailable combination does the job. I was hoping to avoid setting up all the available combinations as the unavailable is a shorter list, but ok, it sounds like it will do the job.

One piece I'm not clear on. Let's say a product has a third attribute, say Gift Box which is a yes/no option. Do we need to account for that in SBA somehow?

"all" the available combinations can be setup by use of the dropdowns on the variation entry page such that alllllll variations are populated with whatever number is desired to be used at the onset, then delete the small quantity that could never exist and then update the quantity of the variations that exist to their desired/assigned quantity. Easypopulate V4 offers export/import of this quantity tracking information to simplify that process if so desired.

As to the "gift box" option. I thought that I had added something to specifically support it and that I had commented on its availability/capability; however, at the moment I'm going to default to a sorry, the gift box option is not currently available, until proven otherwise. :) I do know/recall that I had to work through the possibility of using a checkbox because an unchecked checkbox doesn't show up on the "transmitted" data, making me wonder if the way around that was to consider a checkbox as a non-stock related quantity (regardless of checked or not) or if it required populating product such that they were entered both as with a checkbox and without a checkbox... Darnit... Can't remember and would take either a test or a code review to determine.

@jeking,

Was working on the "gift-box" option (which really offers much more than that as envisioned) and came across something that I thought had been addressed. I have pushed a commit just to address this one "feature" and will look into adding an admin switch to turn it off/on.

The issue is that with regards to items defined in the SBA table, currently either just in-stock quantities in the combinations defined in the admin OR every "mutation" that could exist is presented and those items that are not defined show as out-of-stock. I thought that I had pushed this change before, and maybe I have some separate code set aside, but it irked me that I expected operation to occur as I described above and it doesn't.

So, in plain text:
in the file includes/classes/pad_base.php

Line 492 which is the first line of this code block:

            if ($productAttrAreSBA !== false) {
              $combinations[] = array('comb'=>$newcomb, 'id'=>substr($newid,1), 'text'=>$newtext);
              if ($newisselected) {
                $selected_combination = sizeof($combinations)-1;
              }
            }

Change from:

            if ($productAttrAreSBA !== false) {
              

to:

            if ($productAttrAreSBA !== false && (true /* <- true to only display product variants available as entered, 
                                                         false to display every attribute combination possible from the attributes controller data for that product  */ 
                                                  ? !is_null($productAttrAreSBA) 
                                                  : true)) {
              $combinations[] = array('comb'=>$newcomb, 'id'=>substr($newid,1), 'text'=>$newtext);
              if ($newisselected) {
                $selected_combination = sizeof($combinations)-1;
              }
            }

This will allow showing defined items/variations that are out-of-stock and prevent display of undefined out-of-stock variations. This will mirror what I described above where I indicated regarding defining only a few size/color combinations, the ones that don't exist or are not present in the database will not be displayed in dynamic dropdowns.

I plan to add an additional dynamic dropdown switch to enable/disable that "reality" display which ultimately could end up being "moved" to a variant/product area such that each product could be independently controlled to show all possible based on the attributes controller entries or only those that are defined by sba... Different people have different reasons for each.

As to the "giftbox" option, I haven't pushed my initial effort to github yet, but I have a "basic" version working with consideration of a product's option name being considered as non-stock based that does not require modification of displayed sort order (ie doesn't require non-stock attributes to be last or first, but anywhere within the sort list) and have been able to incorporate it into Dynamic Dropdowns.

At the moment it still also enforces the need of and verification that the provided attributes are "permissable" in the sense that if too few/many attributes are provided as compared to the attributes defined then it considers the product as incorrect. There are a lot of variations that become possible with this which is something I am trying to address. The simplest form of use would be that of one or more checkboxes being considered as non-stock related. It seems that there are still a few issues/kinks regarding having more than one checkbox associated with a product to enforce the existence of the combination(s) when the attributes are stock controlling. Understand though that there is no data passed forward for an unchecked checkbox and having two or more checkboxes results in the "need" for multiple variants (if referring to combined variants).

So, perhaps you can see just at the onset how chaotic it can all get. In working this I've created a separate table to track the various options that are non-stock dependent where they can be defined by being a single product's option value being non-stock dependent, a product's option name being non-stock dependent, a specific option value regardless of product and a complete option name. Convenience of handling it this way is that upon addition of such a new "possibility" the table is also minimized based on the selections already present. A programming trade-off though is once say an option name becomes fully non-stock, the addition of that option name to a new product becomes a "trigger" point at which to discover if the option name should continue to be fully non-stock or if it should be split out to include all product but the new product... Could just collect a huge list of all option values and deal with things that way, but seems like a waste of database space when such "tipping" points can be used.

I plan to push the basic code to github soon and until a decent handler is generated, entry of records will likely have to be by SQL statement which is only going to make things that much more "fun" once the handlers are generated (have to "correct" issues that are intended to be addressed by proper database management). I have some ideas about how to present some of the information in the SBA management screen, but so far mentally the solution is based on one maybe two attributes or values being "optional/non-stock". Any more than that and start talking about the need for "spreadsheets" or "lists" of the possible variants, etc... As for the capacity that has been shown, one could identify a product's options value as being non-stock based (could be added/selected as an "add-on" but would not require a specific stock quantity to be identified), a product's option name as being non-stock based (any selection with the option name group would be non-stock based), an option value regardless of product assignment would be non-stock, and an option name (also regardless of product) would be non-stock based.

Biggest hurdle to overcome is all of the "display" of information/conditions in a useful manner and store owner interaction through the various arrangements. Ideally wouldn't have to modify other files, but in some cases to accomplish that means the display of some sort of intermediary screen adding "steps" to the process... Even attempting to insert javascript in some cases in the admin has not yet been made "easy" without editing a file.

@mc12345678 Thank you for the details and code. It does look like it would address the need I had brought up. Of course, we've gone a different way with this client. The issues and combinations, as you mention, was part of that decision. Thanks for your continued work on this plugin. It is both necessary in many instances and quite complex due to the way many stores need to track these details.

Is there a way to have dropdowns on a page have independent quantities that aren't affected by each other? ie. I'm selling a product (dropdown #1) and then there's the option to add an extra donation (dropdown #2). Let's say the dropdown #1 sells out but people still want to make a donation via dropdown #2. Can it work that way? My previous experience says it can't.

Thanks!

Christian_Wagner:

Is there a way to have dropdowns on a page have independent quantities that aren't affected by each other? ie. I'm selling a product (dropdown #1) and then there's the option to add an extra donation (dropdown #2). Let's say the dropdown #1 sells out but people still want to make a donation via dropdown #2. Can it work that way? My previous experience says it can't.

Thanks!

Took a little noodling, but with the current version of SBA on github, I believe that such a thing is now possible. It's an unusual setup/consideration and a website that I have seen that accepts donations actually has a separate link to the donation direction instead of trying to pack several things into the "product". Guess it's possible, just sounds unusual, anyways:

The setup would be/include this:
In your first dropdown, you would need to have an option like: No thank you for the product in dropdown #1 that would be assigned as non-stock related.
Then, probably best (considering that dropdown #2 is all about donation and not a stock quantity) to assign the product's option name as a non-stock related item and because the option value in dropdown #1 would also be non-stock, then would also assign the product's option value for that option name as non-stock.

So, what is this non-stock feature? Well, I somewhat jumped the gun on functionality by adding the ability for a product's option value, a product's option name, an option value, or an option name to be non-stock dependent without any of the desired/foreseen methods to properly manage the feature. Right now it is more a proof of operation and functionality. Adding in the applicable ways/places to support admin entry (without a SQL statement) is going to take a little bit, but the primary focus is on the function(s) that do the adding/managing of the addition(s) and then in my opinion the interface can follow.

So, how does one add a non-stock related characteristic?

There are four designated "groups" which are considered capable of being non-stock dependent:
All Option ("AO")
All Values ("AV")
Product's Option ("PO")
Product's Value ("PV")

That is used/designated to the field: attribute_type

Then there is the attribute_type_id. This is the applicable options_id or options_values_id depending on whether dealing with an option or a value respectively. The number associated with that is located in the admin->Catalog->Option Names Manager or Option Values Manager respectively. All such non-stock attributes will have an attribute_type_id.

And lastly (currently) is the attribute_type_source_id. This represents to what the option or value is applicable. Since no product can have a products_id of 0, I have chosen 0 to represent the case of either of the All Option/All Values group. If the non-stock feature is to apply to a specific product, then the attribute_type_source_id would be the products_id for that product.

So... Then there is the table that is involved. I didn't do the system any justice by picking a short name, so right now the table is called: products_with_attributes_stock_attributes_non_stock.

Let's assume that in the above example/request that dropdown #2 has an options_id of 23 and that products_id 55 is this one product that is to have this feature. This dropdown is expected to be "available" no matter how many of dropdown #1 is present, also, generally speaking there is no desire to track the quantity "available" of any feature within dropdown #2 because afterall, what kind of a limit would be set for a donation other than perhaps a single large quantity that is probably restricted by other "features" (bank account, payment processor, etc...).

So to make dropdown #2 non-stock the sql (able to be entered into tools->install SQL patches) would be:

INSERT  INTO products_with_attributes_stock_attributes_non_stock  (attribute_type, attribute_type_id, attribute_type_source_id) VALUES  ('PO', 23, 55);

So that generally takes care of dropdown #2 and further means that the SBA table for this product (products_id of 55) does not need to define a quantity for any value within dropdown #2. If however a quantity is entered for one or more values, then that quantity will override the "non-stock" portion of the product's option name.

Now for the one option value within dropdown #1 that will remain "in-stock" while all other options go out-of-stock and are displayed as out-of-stock.

Assume that dropdown #1 has an options_id of 31 and the specific value has an options_values_id of 143. The SQL to add this one feature for dropdown #1 would be:

INSERT INTO products_with_attributes_stock_attributes_non_stock  (attribute_type, attribute_type_id, attribute_type_source_id) VALUES  ('PV', 143, 55);

And now also, the "No Thank You" option value should not be assigned to a variant and should not be assigned a stock quantity unless that specific combination should be controlled as a stock quantity.

With these combinations, then it is expected that if a customer selects the "No thank you" from dropdown #1 and any option within dropdown #2, then the purchase should be possible... (Untested, but falls within the concept.)

Would appreciate feedback on if that works or not and where in the process there is a problem/issue identified. I've notified 2 others about this added feature. One has initiated testing the other has not responded.

Wow. Will let you know if this works. May take a day or 2 to get around to this. Thanks!

mc12345678:

Took a little noodling, but with the current version of SBA on github, I believe that such a thing is now possible. It's an unusual setup/consideration and a website that I have seen that accepts donations actually has a separate link to the donation direction instead of trying to pack several things into the "product". Guess it's possible, just sounds unusual, anyways:

The setup would be/include this:
In your first dropdown, you would need to have an option like: No thank you for the product in dropdown #1 that would be assigned as non-stock related.
Then, probably best (considering that dropdown #2 is all about donation and not a stock quantity) to assign the product's option name as a non-stock related item and because the option value in dropdown #1 would also be non-stock, then would also assign the product's option value for that option name as non-stock.

So, what is this non-stock feature? Well, I somewhat jumped the gun on functionality by adding the ability for a product's option value, a product's option name, an option value, or an option name to be non-stock dependent without any of the desired/foreseen methods to properly manage the feature. Right now it is more a proof of operation and functionality. Adding in the applicable ways/places to support admin entry (without a SQL statement) is going to take a little bit, but the primary focus is on the function(s) that do the adding/managing of the addition(s) and then in my opinion the interface can follow.

So, how does one add a non-stock related characteristic?

There are four designated "groups" which are considered capable of being non-stock dependent:
All Option ("AO")
All Values ("AV")
Product's Option ("PO")
Product's Value ("PV")

That is used/designated to the field: attribute_type

Then there is the attribute_type_id. This is the applicable options_id or options_values_id depending on whether dealing with an option or a value respectively. The number associated with that is located in the admin->Catalog->Option Names Manager or Option Values Manager respectively. All such non-stock attributes will have an attribute_type_id.

And lastly (currently) is the attribute_type_source_id. This represents to what the option or value is applicable. Since no product can have a products_id of 0, I have chosen 0 to represent the case of either of the All Option/All Values group. If the non-stock feature is to apply to a specific product, then the attribute_type_source_id would be the products_id for that product.

So... Then there is the table that is involved. I didn't do the system any justice by picking a short name, so right now the table is called: products_with_attributes_stock_attributes_non_stock.

Let's assume that in the above example/request that dropdown #2 has an options_id of 23 and that products_id 55 is this one product that is to have this feature. This dropdown is expected to be "available" no matter how many of dropdown #1 is present, also, generally speaking there is no desire to track the quantity "available" of any feature within dropdown #2 because afterall, what kind of a limit would be set for a donation other than perhaps a single large quantity that is probably restricted by other "features" (bank account, payment processor, etc...).

So to make dropdown #2 non-stock the sql (able to be entered into tools->install SQL patches) would be:

INSERT INTO products_with_attributes_stock_attributes_non_stock (attribute_type, attribute_type_id, attribute_type_source_id) VALUES ('PO', 23, 55);

> 
> So that generally takes care of dropdown  #2 and further means that the SBA table for this product (products_id of  55) does not need to define a quantity for any value within dropdown  #2.  If however a quantity *is* entered for one or more values, then  that quantity will override the "non-stock" portion of the product's  option name.
> 
> Now for the one option value within dropdown #1 that  will remain "in-stock" while all other options go out-of-stock and are  displayed as out-of-stock.
> 
> Assume that dropdown #1 has an  options_id of 31 and the specific value has an options_values_id of 143.  The SQL to add this one feature for dropdown #1 would be:
> ```
INSERT INTO products_with_attributes_stock_attributes_non_stock  (attribute_type, attribute_type_id, attribute_type_source_id) VALUES  ('PV', 143, 55);

And now also, the "No Thank You" option value should not be assigned to a variant and should not be assigned a stock quantity unless that specific combination should be controlled as a stock quantity.

With these combinations, then it is expected that if a customer selects the "No thank you" from dropdown #1 and any option within dropdown #2, then the purchase should be possible... (Untested, but falls within the concept.)

Would appreciate feedback on if that works or not and where in the process there is a problem/issue identified. I've notified 2 others about this added feature. One has initiated testing the other has not responded.

Christian_Wagner:

Wow. Will let you know if this works. May take a day or 2 to get around to this. Thanks!
Mind you. There is one other stock aspect not discussed nor otherwise directly addressed (yet?). The above setup/condition would also depend on the product as a whole having quantity available as seen on the admin's product info page. Note that depending on previous stock style entries that if the product was synchronized with the existing variants then when those variants have gone out-of-stock, the product would be considered out-of-stock. There currently is not an "option" to not modify the overall stock quantity if all attributes are non-stock attributes. Call it an oversight if you wish, but certainly is something to address/consider. The question then becomes should it be an option or a standard that such stock quantities are not modified. I believe the answer to that question seeing how the "feature" is being proposed to be used is that it be an option applicable/possible for each product.

That said, the concepts to be applied to the SBA admin screen are starting to get "busy" even with javascript/jquery being considered. :)

This is a repeat of post #222, asking "Is there a way to assign a different SKU/model for each product variant using this mod?"

Is anything like this in the pipeline? A client of mine needs different SKU's for each product variants.

Thanks guys.

frank18:

This is a repeat of post #222, asking "Is there a way to assign a different SKU/model for each product variant using this mod?"

Is anything like this in the pipeline? A client of mine needs different SKU's for each product variants.

Thanks guys.
Been a part of the code for a couple of years now. It's "disguised" as a customid (usable) however desired. At one point it replaced the model info, then it was a separate piece of data. Seeing how it is being desired to be used, I'm in the works of making a switch available to support all three modes of keeping as a separate "result", just replacing the model, or both. Model replacement has been: if there is a customid then use it, otherwise use the model.

mc12345678:

Been a part of the code for a couple of years now. It's "disguised" as a customid (usable) however desired. At one point it replaced the model info, then it was a separate piece of data. Seeing how it is being desired to be used, I'm in the works of making a switch available to support all three modes of keeping as a separate "result", just replacing the model, or both. Model replacement has been: if there is a customid then use it, otherwise use the model.

Huh! That is the one I played around with, modified the invoice a bit and to me it looks perfect :cool:. I emailed the suggestion to my client, let's see what he has to say :smile:

frank18:

Huh! That is the one I played around with, modified the invoice a bit and to me it looks perfect :cool:. I emailed the suggestion to my client, let's see what he has to say :smile:
@frank18,

Uploaded a change/addition that should add the ability to replace the products_model with the customid (4 options related) based on an admin setting in the configuration->stock settings when retrieving data associated with an order. The customid field will always remain "available" for reading, but the model (products_model) data is what can be affected. Potential remains to later add a way that this can occur on a per-product basis.
Also as part of the upload/review is that I did see where ZC 1.5.1 may have gotten negatively affected by other changes that had been made for improvement to more recent versions of ZC, so those have been corrected.

As can be seen here, I've received no comment on the ability to have option values or option names be identified as non-stock items. Generally speaking the instructions all around still need to get caught up with the capability of the plugin as related to its ability there are a number of errors in the documentation that was written to support the version still available for download as a plugin from this website.

I'm working on those, but not nearly at the pace of other software, projects, and other improvements for this.

I grabbed the files from https://github.com/mc12345678/Stock_By_Attributes_Combined today and tried applying them to my test site. After installation I get a blank page in the admin and the error log file points me to includes/classes/class.products_with_attributes_class_stock.php line 509. It reads:

      
      if (!empty(stock_attributes_list)) {
        return $stock_attributes_list;
      } else {
        return false;
      }

I changed it to:

      
      if (!empty($stock_attributes_list)) {
        return $stock_attributes_list;
      } else {
        return false;
      }

This allowed the site to function without error, so that seems like step in the right direction. I am struggling to get the dynamic dropdowns functioning, but I wanted to report this and make sure it looked right to you mc12345678.

fbroz:

I grabbed the files from https://github.com/mc12345678/Stock_By_Attributes_Combined today and tried applying them to my test site. After installation I get a blank page in the admin and the error log file points me to includes/classes/class.products_with_attributes_class_stock.php line 509. It reads:

  if (!empty(stock_attributes_list)) {
    return $stock_attributes_list;
  } else {
    return false;
  }

> 
> I changed it to:
> 
> ```
      
      if (!empty($stock_attributes_list)) {
        return $stock_attributes_list;
      } else {
        return false;
      }

This allowed the site to function without error, so that seems like step in the right direction. I am struggling to get the dynamic dropdowns functioning, but I wanted to report this and make sure it looked right to you mc12345678.

Your suggested revision is correct. I have no idea how that has been missing for so long without obvious error from either the store or admin side, though I have seen where I changed approaches at obtaining the information provided by that code (incorporated return of the ids into a separate function that basically was designed to return such related information).

Thank you, the master branch has been updated with that correction.

Now as far as dynamic dropdowns...

They are setup initially to operate in the condition that they have been designed/rewritten. Currently, the only fully identified functional version is when a product has multiple option names, each with at least one option value from which to select. Suggestion is to use the standard dropdown for that/those option names (attributes). If a product has only one option name, then the option name "type" of SBA Simple Select (Dropdown) should be available in the option name manager and that will provide the text/content associated with out-of-stock (or whatever chosen verbiage).

The other potential options for Dynamic Dropdowns have been modified slightly to at least maybe be functional, but there could be issues with those out-of-the-box. Beyond that, because javascript is involved, be sure that your page(s) validate when using an html validator... If they do not, the javascript may not fire because of an improperly presented page.

Thanks for the quick reply mc12345678!

I am working on upgrading an older site (zc 1.3.8a) and running into some issues with SBA and dynamic dropdowns. On the old site, the Option Names are all of Option Type "Dropdown". It seems like your guidance in previous posts (such as https://www.zen-cart.com/showthread.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1300190#post1300190) is to use Option Type "SBA Select List (Dropdown) Basic". Should I switch to this Option Type if I want to use this modern software? I see from your previous reply that "Dropdown" is the right choice for me since all of my option names will have more than one option value.

That issue aside, the dropdowns behave strangely. I have Enable Dynamic Dropdowns set to '2' and Product Info Multiple Attribute Display Plugin set to 'sba_sequenced_dropdowns' in the dynamic dropdowns configuration. Here is a link to a product set up with 'Dropdown':

https://www.tokyopenshop.com/shop2/index.php?main_page=product_info&cPath=11&products_id=18

and here is one set up with 'SBA Select List (Dropdown) Basic':

https://www.tokyopenshop.com/shop2/index.php?main_page=product_info&cPath=11&products_id=77

The page loads slowly to populate the dropdowns, and then the first dropdown list items all say "Back Order:" for some reason. Adding to the cart fails also. Any idea what I'm doing wrong?

I see that I have many HTML validation failures.... OOPS! I will work on fixing those and see if I get this resolved.

fbroz:

Thanks for the quick reply mc12345678!

I am working on upgrading an older site (zc 1.3.8a) and running into some issues with SBA and dynamic dropdowns. On the old site, the Option Names are all of Option Type "Dropdown". It seems like your guidance in previous posts (such as https://www.zen-cart.com/showthread.php?47180-Stock-by-Attribute-v4-0-addon-for-v1-3-5-1-3-9&p=1300190#post1300190) is to use Option Type "SBA Select List (Dropdown) Basic". Should I switch to this Option Type if I want to use this modern software? I see from your previous reply that "Dropdown" is the right choice for me since all of my option names will have more than one option value.

That issue aside, the dropdowns behave strangely. I have Enable Dynamic Dropdowns set to '2' and Product Info Multiple Attribute Display Plugin set to 'sba_sequenced_dropdowns' in the dynamic dropdowns configuration. Here is a link to a product set up with 'Dropdown':

https://www.tokyopenshop.com/shop2/index.php?main_page=product_info&cPath=11&products_id=18

and here is one set up with 'SBA Select List (Dropdown) Basic':

https://www.tokyopenshop.com/shop2/index.php?main_page=product_info&cPath=11&products_id=77

The page loads slowly to populate the dropdowns, and then the first dropdown list items all say "Back Order:" for some reason. Adding to the cart fails also. Any idea what I'm doing wrong?
You can actually use either of the dropdown options. The sba version adds features not made available through the standard dropdown, though currently those features are not necessary if using multiple attributes and/or dynamic dropdowns.

As to the back order: "feature", it appears that some code in the includes/classes/pad_sba_sequenced.php file was prematurely incorporated to the files... I have a similar display on my test site depending on a few settings. The idea is/was that either product would be displayed as out-of-stock or as on back order depending on if checkout was allowed with 0 or negative stock. Further that the word(s) would be easily modifiable (language variable instead of hard-coded as it is now) to something else as desired...

Trying to look back at what "version" of the file would be considered stable to apply now, versus possibly waiting a couple of hours for resolution.

Still good though to correct validation issues, which are typically the problem with dynamic dropdowns, but in this case it's not you, it's me... :P (yes sounds like a break up, but I will find the intended solution to the issue.)

For the time being, setting $backorder to false instead of true will "restore" operation.

Includes/classes/pad_sba_sequenced_dropdowns.php

Line 285:
Change:

$backorder = true; 

To:

$backorder = false; 

Thanks mc12345678, that did change the text back to 'out of stock' in the first menu, which I am still working on wrapping my head around.

When I add a product to the cart and try to view the cart page, I get a blank page and this error message in the logs:

[04-Aug-2017 13:14:16] PHP Fatal error: Call to undefined function cartproductcount() in /myhtmlpath/shop2/includes/modules/pages/shopping_cart/header_php.php on line 170

I do see that function in includes/classes/class.products_with_attributes_class_stock.php and also one that is commented out in includes/functions/extra_functions/products_with_attributes.php

Any idea why I am seeing this? Thanks in advance.

fbroz:

Thanks mc12345678, that did change the text back to 'out of stock' in the first menu, which I am still working on wrapping my head around.

When I add a product to the cart and try to view the cart page, I get a blank page and this error message in the logs:

[04-Aug-2017 13:14:16] PHP Fatal error: Call to undefined function cartproductcount() in /myhtmlpath/shop2/includes/modules/pages/shopping_cart/header_php.php on line 170

I do see that function in includes/classes/class.products_with_attributes_class_stock.php and also one that is commented out in includes/functions/extra_functions/products_with_attributes.php

Any idea why I am seeing this? Thanks in advance.
How did this site upgrade get performed? Sounds like it wasn't to: http://www.zen-cart.com/entry.php?3-How-do-I-rebuild-my-site-on-the-new-version-instead-of-upgrading

Changes to that file have really become a minimum though they may not have been fully removed yet. That was something added in that at the time was looking at whether the combination of product stored in everyone's saved cart plus what was being added to the user's current shopping cart would cause the product quantity to go negative... basically if you wanted to prevent someone from getting an item, logon, add the maximum available quantity and log out... no one would have been able to add anything to their cart unless maximums were imposed/required...

Basically if the file is not listed in the version specific folder, and it is modified on the store for an older version, then it should be restored to whatever the file should be if sba was not installed...

There are two files that come to mind as an exception to that statement. They are template override files in the main includes folder but haven't changed at least up to and including 1.5.5 within the 1.5.x series covered by this plugin.