Weight of options limited to 2 decimal places

[fettlebox]

I'm offering a product option. The additional weight is 3g ie 0.003kg. It will only allow me up to 2 decimal places. We ship by weight so this is important.

[Dirty Butter]

I checked the structure of the _inventory table in the database, and my product_weight is decimal(10,3), which should mean a total of 10 characters with a maximum of 3 to the right of the decimal.

I tested my 5.1.1 store by changing the weight of an item to use 3 decimals with Display Basket Weight checked, and it worked properly.

[fettlebox]

The product weight isn't a problem. I can set weight to 3 decimals. The problem is with product options where the weight is only to 2 decimals

[Dirty Butter]

Sorry, I don't have Options set. BUT I was on the right track. Look at weight in the _options_set_member table and change decimal (16,2) to (16,3) and it should work. See Bsmither's next comment.

[bsmither]

If you can access your database directly, look at table CubeCart_option_assign, column option_weight.

Currently it is set to DECIMAL(10,2). Feel free to change it to DECIMAL(12,4).

If you find it difficult to access your database (with phpMyAdmin, for example), then in admin's Maintenance, Query database (Advanced) (dangerous tool!), enter:

ALTER TABLE `pre_CubeCart_option_assign` MODIFY COLUMN `option_weight` DECIMAL(12,4) NOT NULL DEFAULT '0.0000';

where pre_ is the table prefix as indicated just below the fat red warning banner.

[Dirty Butter]

Sorry, I quit looking when I found one option table with weight in it. Do both need changing, or did I just tell fettlebox wrong? I'll delete my comment if it's wrong.

[bsmither]

CC_options_set_member table does not record any particulars. Only an association(s) between options and products.

[Dirty Butter]

CC_options_set_member table does not record any particulars. Only an association(s) between options and products.

I must have leftover rows in my _options_set_member table from earlier versions then.

[fettlebox]

I made the change via phpMyAdmin & back in cc admin changed the weight of the option to 0.002 & saved. No change - back showing as 0.00. I cleared the cache & tried again - no difference. If I change it to 0.01 it sticks.

[Dirty Butter]

Ugh. I sure wish I knew how to help you! If the database is allowing 3 decimal digits, that would appear to mean there's some place in the code that is still set to only allow 2 digits, or needs to explicitly allow 3??? Glad you made a bug report of this. You can't be the only one who needs this!

[fettlebox]

Just noticed - screenshot above is from cc_cc_CubeCart_option_assign.

I also have one called cc_CubeCart_option_assign.

It shows as below;

If I go into edit is shows the decimal as 10,2

[Dirty Butter]

Have you tried changing that to 12,3 in the structure of that table?

[fettlebox]

just edited by last post - the option_weight is 10,2 in the last screenshot not 12,2 as I originally wrote.

Back in the edit recommended by Bsmithers I changed it to 12,4 & when that didn't work I tried 12,3 which is what it's currently on. Didn't work either.

[bsmither]

You are correct in that CC514 uses a PHP function to "format" a given number into a more human-readable format.

Instead of 4357890.45, the function makes it look like 4,357,890.00 (with options to use the local character for the thousands separator and decimal mark -- not that CC5 makes use of the local characters).

In the file products.index.inc.php, find line 776:

$assign = array('set_enabled' => '1', 'option_price' => number_format(0,2), 'option_stock' => 0, 'option_weight' => number_format(0,2));

Change that to (0,4) or (0,3) as desired.

BUT! If you had saved an option with an option_weight specified, then you should see it in the table. The saving of the data into a database record happens around line 230. And if the database is set to accept three or four decimals, it should take it. Line 776 is involved in showing the databased data in the admin screens.

Just to point out, in cart.class.php, line 721, CC514 will format the display of the total basket weight to three decimal places.

I am not finding any formatting of the weight (or any of the product data) in the skin files, so I think we are good there.

Note: Formatting anything according to the dictates of the skin should be handled by the skin (the view). So, in my opinion, there shouldn't be allowed any truncation/formation of floating-point values in the database (the model) or data collection web forms/processors (the controller). Just my opinion.