Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I've recently setup https://drupal.org/project/uc_bitcoin to accept payments in my Ubercart store using the Bitcoin cryptocurrency.
As such, I'd like to set the Precision on the Currency Format settings up to 8, but currently the only options are 0, 1, 2.
Patch included to allow the Currency Format "Number of decimal places" value on the form to be 0, 1, 2, 3, 4, 5, 6, 7, 8.
I am unsure if there are other consequences, such as database schema or other areas which would need to support this change. I just changed the values available on the Store Configuration form.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | ubercart-precision_up_to_8-2538722-5.patch | 2.3 KB | nerdcore |
| |||
| #1 | ubercart-precision_up_to_8-2538722-1.patch | 562 bytes | nerdcore |
| |||
Comments
Comment #1
nerdcore CreditAttribution: nerdcore as a volunteer commentedComment #2
nerdcore CreditAttribution: nerdcore as a volunteer commentedIt seems this only partially addresses the desired solution.
I've applied the patch and set the precision for the Currency Format to 8. This appears to work, however when I set a Product's price to "0.12345678" to test, it got rounded to "0.12346000". Where is this rounding coming from? Why 5 decical places?
Comment #3
nerdcore CreditAttribution: nerdcore as a volunteer commentedI see now that the fields "list_price", "cost", and "sale_price" in the database table uc_products are all set to type "decimal(16,5)".
Could we get this raised to (16,8) instead?
Thanks.
Comment #4
TR CreditAttribution: TR commentedMy feeling is that since this isn't an issue that affects real currencies (all of which have precision 2 or less) it should be done in uc_bitcoin if at all possible. If we allow higher precisions, then people will start using them because of course everyone wants the best precision, but I'm positive that will cause its own set of problems.
I think if you write a hook_form_alter() for the uc_bitcoin module you can modify the store settings form to allow higher precisions for when the store currency is bitcoin. The precision is used for display purposes only, so alternatively you could override some theme functions to do the same thing. If you want your store currency to be bitcoin, you would also have to write a hook_update_N() to alter the database schema, as you discovered. But all this could be done in uc_bitcoin.
But do you really want the store currency to be set to bitcoin, as opposed to using a normal currency and just accepting payment in bitcoins? uc_bitcoin is a payment gateway. Using bitcoin as a store currency presents problems other than display; because the bitcoin exchange rate fluctuates wildly you will still need some way to dynamically adjust all your prices, won't you? Or do you really want prices fixed to fractional bitcoins?
Comment #5
nerdcore CreditAttribution: nerdcore as a volunteer commentedI would like an Ubercart store which operates solely in BTC and has no relation to values in what you call "normal" currencies.
I'm a bit perplexed why the database schema already allows for 5 decimal places when the UI only offers choices in the range 0-2.
Attached is a patch which includes #2 but also alters the database schema in the uc_product module to increase the three price fields in the uc_products table from decimal(16,5) to decimal(16,8).
Comment #6
TR CreditAttribution: TR commentedWe need extra places to account for rounding and to make sure that taxes get calculated properly.
Comment #7
longwaveI am also wary of making this change in core as I do not want to introduce any further rounding problems, and it's not even needed for all stores that accept Bitcoin - only ones that actually price their items in BTC. However this looks like it is all solvable via hook_form_alter, hook_schema_alter and maybe a few others. Therefore my suggestion is to add a uc_bitcoin_store or similar submodule to your project that alters the price fields and settings forms in order to achieve this.
Comment #8
longwave