closes odoo/odoo#70936 Taskid: 2412172 Related: odoo/enterprise#18366 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces a new utility function: 'groupBy'. It is similar in API and result as the underscore method of the same name. X-original-commit: 834a1967161dc537cb2d5543314a062dbac08f9c
Add a "sortBy" helper to core utils. This function takes an array and an optional criterion as arguments and returns a new array sorted according to the given criterion.
In JavaScript, the following computation introduces numerical errors: ``` Math.pow(10, -4) = 0.00009999999999999999 Math.pow(10, -5) = 0.000009999999999999999 ``` In the context of `round_decimals`, such errors propagate to `round_precision`, ultimately leading to inconsistencies between Python and JS (see #47300 for detailed use case). Instead of computing `Math.pow(10, decimals)`, we parse the scientific notation to prevent such inaccuracies. We also introduce tests in line with the Python tests. opw-2205092 closes odoo/odoo#47694 X-original-commit: cb471897bfa08d1fee6a9f49e90d9c120e1733fc Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This reverts commit d6b854306cae245343a7acb9edc4178d245a49fe. The reverted commit introduced issues in patching class methods. Introducing getters in the patch function is not actually compatible with the original method patching. Test for patch method is also introduced to guard patch from future invalid modification that happened. A more robust way of patching classes is now being developed. closes odoo/odoo#47557 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previous implementation of patch (web.utils) only allows patching methods. This commit allows patching getters as well. closes odoo/odoo#47047 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, negative numbers are never rendered as human readable (e.g. 34000 -> 34k). closes odoo/odoo#42789 Taskid: 2160790 X-original-commit: b51877c4c4c9d8cd873dd0205954fd807d62ee01 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The formatting of very big numbers (like 1.0045e+22) was not handled adequately by the function 'human_number' in web.utils. For those numbers, it seems more appropriate to use the scientific format. The only difference introduced here is the following. Beyond a magnitude of e+21, we represent the numbers by themselves but we keep the number of decimals provided as parameter (or zero by default) and we remove useless zero decimals like in the other cases. For instance, 1.0045e+22 is replaced by 1e+22 instead of 1.00e+22 if ask 2 decimals of precision (and by 1.005e+22 for 3 decimals). We have also fixed a small bug occuring in the previous version of the function: the symbol 'E' was never used. So by the past the above number would have be represented as 10045000P and, even worse, 1.01e+45 by 1.012e+28P. closes odoo/odoo#31140
- added unaccent search on POS customer/partner and product - moved unaccent from "mail.utils" to "web.utils" - added more character to make function accurate We might use str.normalize(from ES6) but the problem is str.normalize method can not consider some double characters i.e. accented character when normalized it returns 2 normal characters and normalize method returns single character, so here custom unaccent method is used to normalize the string What we can improve here: We can use str.normalize method and check if string is still have unaccented charaters that we can call our unaccent method but this unaccent method is also working and performing well closes odoo/odoo#27671