[FIX] web: human numbers and percentages

A recent modification of the float and integer
formatters allowing the rendering to be human readable
causes a bug in the percentage formatter for large values.
The reason is that the latter formatter uses formatFloat (wich can
now produce 'numbers' like 3k) and then parse the result. In the case
of 3k an error is raised since 3k is not recognized as a true number.

This fixes avoid to parse the number in case it has been formatted
to be 'readable'. Note that the parsing was essentially used
to produces better percentages like 10% instead of 10.00%.
This is not necessary in our case since utils.human_number takes care
of the unwanted (not all) decimals for us (the original number is always
rounded by utils.human_number).

1 files changed, 7 insertions, 2 deletions

diff --git a/addons/web/static/src/js/fields/field_utils.js b/addons/web/static/src/js/fields/field_utils.js
index 750cf055cdf..9d40c88019d 100644
--- a/addons/web/static/src/js/fields/field_utils.js
+++ b/addons/web/static/src/js/fields/field_utils.js
@@ -354,11 +354,16 @@ function formatMonetary(value, field, options) {
  * @param {number | false} value
  * @param {Object} [field]
  * @param {Object} [options]
+ * @param {function} [options.humanReadable] if returns true, parsing is avoided
  * @returns {string}
  */
 function formatPercentage(value, field, options) {
-    value = formatFloat(value * 100, field, options) || '0';
-    return parseFloat(value) + "%";
+    options = options || {};
+    var result = formatFloat(value * 100, field, options) || '0';
+    if (options.humanReadable && options.humanReadable(value * 100)) {
+        return result + "%";
+    }
+    return parseFloat(result) + "%";
 }
 /**
  * Returns a string representing the value of the selection.