forced option and value selection not enforced if customer tampers with HTML DOM

I'm using V1.3.9H, and I don't this is a version-related issue, I occasionally found this bug:

On the product detailed page, in the option and value selection DIV block which contains quite a few drop-down boxes I have a option value named "please select from below", this value is marked as "Display Purposes Only" and "Default Attribute to be Marked Selected", after I deleted this whole DIV block using Firebug, I can add the product into cart without needing to choose from drop-down boxes, so the option value's amount and weight was not added to cart too

you can reproduce this bug here:

http://demo.zen-cart.cn/test-25-special-10-sale-attribute-priced-p-78.html

see screenshot:

From the picture you can see the cart total is zero, customer can checkout without payment

Cart total "0" and dollar total "0"
What are they getting???

Couple of things with this.

1. Able to repeat condition in a ZC 1.5.4 store to an extent:
   Same default product used as is, no change to the attrbutes controller, product appears and can be added without selecting a color. Now, and this is a bit complex, but simulates the described firefox "hack". If the product is in the cart and the cart is displayed, the attributes of the product are modified to add a please select option value set as default for display only sort order 0. Then the product name is selected taking the individual back to the product description and any previously selected attributes are then "highlighted" the color option remains blank, but the product can again be added without selection of color and any applicable attribute changes/prices/weights.... Effectively the choice of color is not presented and the absence of a color selection is not challenged.

2. I see no modification of the product information as described as being applied (ie. There is no assignment in the presented sample product of a default value.)
3. The uri rewriter being used does not support returning to the product with the attribute selections from the cart. This could be template related, but probably something to do with the applicable header_php.php file in the includes/modules/pages directory structure which is not specifcally template related.
4. Assuming that one were to "hack" the page for submission as eluded in the OP, I don't exactly see the direct consequence to the store as it appears that the options omitted by the hack affect shipping additionally the ability to properly identify a product to be shipped, therefore nothing seems possible to send and therefore it is mostly a waste of everyone's time to have done the hack...

Mostly leading to, what appears to be a good suggestion is that when comparing the possibility of using a radio button as compared to a dropdown, a dropdown is a better option as a dropdown always has an active option, whereas a radio button set could be non-active. But then, there is the "hack" of completely removing all indicaton of an attribute. ZC base code does not have a stock quantity by which it truly requires an attribute be selected in order to process the product... This would be something that could/should be addressed through an add-on that tracks/identifies product as being available only when the applcable attribute(s) has been selected... Will say that this particular condition I don't think is properly addressed in one such plugin and is going to be added to the list of applicable issues.

mc12345678:

Couple of things with this.

1. Able to repeat condition in a ZC 1.5.4 store to an extent:
   Same default product used as is, no change to the attrbutes controller, product appears and can be added without selecting a color. Now, and this is a bit complex, but simulates the described firefox "hack". If the product is in the cart and the cart is displayed, the attributes of the product are modified to add a please select option value set as default for display only sort order 0. Then the product name is selected taking the individual back to the product description and any previously selected attributes are then "highlighted" the color option remains blank, but the product can again be added without selection of color and any applicable attribute changes/prices/weights.... Effectively the choice of color is not presented and the absence of a color selection is not challenged.

2. I see no modification of the product information as described as being applied (ie. There is no assignment in the presented sample product of a default value.)
3. The uri rewriter being used does not support returning to the product with the attribute selections from the cart. This could be template related, but probably something to do with the applicable header_php.php file in the includes/modules/pages directory structure which is not specifcally template related.
4. Assuming that one were to "hack" the page for submission as eluded in the OP, I don't exactly see the direct consequence to the store as it appears that the options omitted by the hack affect shipping additionally the ability to properly identify a product to be shipped, therefore nothing seems possible to send and therefore it is mostly a waste of everyone's time to have done the hack...

Mostly leading to, what appears to be a good suggestion is that when comparing the possibility of using a radio button as compared to a dropdown, a dropdown is a better option as a dropdown always has an active option, whereas a radio button set could be non-active. But then, there is the "hack" of completely removing all indicaton of an attribute. ZC base code does not have a stock quantity by which it truly requires an attribute be selected in order to process the product... This would be something that could/should be addressed through an add-on that tracks/identifies product as being available only when the applcable attribute(s) has been selected... Will say that this particular condition I don't think is properly addressed in one such plugin and is going to be added to the list of applicable issues.

My sincere thanks and respect to mc12345678 for your long tying and detailed explanation! now I know this bug is not easy to solve, I'd wait...

fast8:

My sincere thanks and respect to mc12345678 for your long tying and detailed explanation! now I know this bug is not easy to solve, I'd wait...

Glad that there is/was some helpful information in that.

So, it's not exactly the "difficulty" involved, but the various conditions that can exist and there's how someone wants their store to operate. For example, some use a radio button selection for say download files. The first option is set as a default, and css is used to hide that option, expecting that if the product is added to the cart that because the default option is still active that the customer will be alerted. But as described above, if the option name is not presented to the code for processing then there is no "default" attribute provided and no "oops" message. There further is no "required" attribute option other than for a text box. So again in a default cart there is less possibility of a check to expect/require an attribute be present.

Now something not further discussed above but has been seen by someone else that had such an "issue" with attributes, is the relationship in time between when the product was applied to the cart and when attributes became price deciding for that product. A situation observed is that 1) a product is added to a store, 2) a customer adds it to their cart while logged in so it gets stored with their profile, 3) at some point later the product is modified to "require" attributes, 4) customer logs in and their saved product is added to their cart automatically, 5) customer can check out with the product in their cart but without the "necessary" attribute(s). The price being determined based on the current settings which could mean $0.00 because of the absence of selected attributes. There are plenty of protections added to address over-populating the data sent to ZC to prevent problems, but in this case there isn't something preventing removal of characteristics from a product such as the Web page modification to remove the entire code section that provides the attribute selections for processing. It does cause a hiccup in distribution, but such as this product, what's going to be shipped if there is nothing really selected?

Whatever the case, I would recommend posting the issue(s) experienced (start a new thread if needed), the conditions necessary to reproduce the issue and seek resolution rather than sit back and wait on something that may not be a priority to others because "no one" is reporting an issue...

As to a similar feature being incorporated into another attribute related stock tracking program, that has been completed for some time now and the customer is notified if they have chosen a tracked product but haven't submitted the necessary attribute data and therefore attempted to purchase a product that doesn't have the desired/necessary options selected.

I hate to bump an old thread, however I have been experiencing this issue on and off since upgrading to 1.54f. I am using a custom template, and unfortunately changing it is out of the question, so I am wondering, has this issue been addressed or a work around figured out? I have several customers, who I presume by accident, end up completing orders that have a zero dollar cost code, minus the minimum for shipping. It is like the device or browser they use does not recognize the attributes option (I am using a dropdown box). I generally catch these before shipping, however with employees and a growing business, I would greatly prefer a solution that does not cause manual steps to be taken each and every time this happens.

I am fortunate I do not have to pay a fee every time I have to refund a customer, otherwise this would be a cart breaking bug.

A couple of things. How often do the selectable options change? Ie, is an attribute added/deleted frequently? I ask, because I believe up until ZC 1.5.6 (probably have to confirm this operation) if a product is stored in one's cart because they have logged in, then the available product options change such that the previously chosen options no longer exist, then when they again log in, the product is attempted to be added to the cart, but the options are removed with the "product" still present. This tends to cause the zero charge for the product but still have everything else go through.

The other question is does the dropdown list have an attribute that is a default and for display only? Such as: please select a color? Having that as a first option tends to help resolve that issue.

As to the template, the code is open source. Anything can be made to work with newer more secure and functional software...

I don't really ever change the attributes. Very very rarely. This issue has only been happening with 1, maybe 2 customers, and it seems to only happen with them. After finding this thread again (and finding my own post, and your reply to boot!), it makes me realize that this is likely done on purpose as an effort to get free items should a less conscious staff member be packaging orders and not notice that the specific item in the middle of a list of twenty has a price of 0...

Either way, it doesn't happen often, but I would like to solve this bug as I am concerned about either the above or for stock management/inventory purposes. Adding a non-selectable attribute at the beginning of the dropdown box sounds like a decent idea. Is this confirmed that it fixes the glitch? I have about 600 products I would have to add this too. I suppose something like Easy Populate would be the go to tool for this.

Koda:

I don't really ever change the attributes. Very very rarely. This issue has only been happening with 1, maybe 2 customers, and it seems to only happen with them. After finding this thread again (and finding my own post, and your reply to boot!), it makes me realize that this is likely done on purpose as an effort to get free items should a less conscious staff member be packaging orders and not notice that the specific item in the middle of a list of twenty has a price of 0...

Either way, it doesn't happen often, but I would like to solve this bug as I am concerned about either the above or for stock management/inventory purposes. Adding a non-selectable attribute at the beginning of the dropdown box sounds like a decent idea. Is this confirmed that it fixes the glitch? I have about 600 products I would have to add this too. I suppose something like Easy Populate would be the go to tool for this.
Not exactly sure (at the moment) if adding the default, display only attribute completely resolves the issue, this is/was somewhat dependent on what else is installed to the cart and the process of checking out. I can say that such a change does not require mass population tools as ZC has a built in feature to copy an attribute to multiple product/categories. Thus a single attribute could be setup on one product and then that attribute could be copied across to all of the other applicable product. This or related features can be found in Option Names Manager and Option Values Manager. I thought there was another location, but not finding it at the moment.