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

[mc12345678]

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.

[mc12345678]

@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.

[jeking]

@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.

[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!

[mc12345678]

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.

[Christian_Wagner]

Wow. Will let you know if this works. May take a day or 2 to get around to this. 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.

[mc12345678]

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. :)

[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.

[mc12345678]

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.

[frank18]

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 . I emailed the suggestion to my client, let's see what he has to say