- Create a product with: Cost: 60.80 Quantity On Hand: 999.0 - Go to Inventory / Reporting / Inventory Valuation - Click on export all (little button next to "Inventory at date") The field "Total value" have too many decimals: 60739.2000000004 This occur because of the multiplication: it yield the correct value (60739.2), but every rounding attempt done, even in the ORM, will mess up the representation https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333 opw-2438384 closes odoo/odoo#67543 X-original-commit: 67cf82962688360cfe25c6b2118a7dbd17a6ee95 Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
When attempting to resize or crop an attachment through the '/web/image' route, if the attachment isn't actually an image (even if the record's mimetype says so) or doesn't match one of the format supported by PIL (Python Imaging Library) - like Apple's HEIF - the request crashes with a "500 Internal Error". Although it makes sense to return a response with an HTTP error code, a more sensible approach would be to return a "404 Not Found" response instead. The point by handling the Exception thrown by PIL and returning a 404 status code is to more closely match the semantic of this HTTP status code. Getting a resized version of a non-image doesn't really make sense as this resource doesn't exist at all ; hence the "404 Not Found" response. On the other hand returning a "500 Internal Error" would denote that a legitimate request failed on the server side, which is not the case here. Note: this difference of semantic, even if only visible in a regular browser, has its importance in the mobile apps because we use it to given a meaningful feedback to the user in case if failed HTTP requests. Note: the mimetype detection could be improved to ease the handling of this kind of errors but would require too much changes to be done in stable branch. Steps to reproduce in Discuss: - rename an HEIF file with a ".jpeg" extension - upload it in a chat window => the thumbnail in the chat window throws an HTTP error 500 opw-2417172 closes odoo/odoo#63767 X-original-commit: 873bc2aa5a8fcfc0664fc5ca70f789911873d583 Related: odoo/enterprise#15456 Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com> Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Some ttf fonts used to sign are shipped does not come with a clear licensing. Also some of them does not have accented characters. With this commit, they are replaced with better ones and their accompanying Open Font License. Also, before this commit, any file in the font directory was read to be rendered by the sign widget. With this commit, only `ttf`, `otf` and 'woff[2]' files are read, this allows to store the license file alongside with the font.
5c4544fb2943e63fc1e0f5ae1e7e250a5a2b2cf1 reordered some of the operations at the export toplevel, and in doing so moved the filtering of the xid out of the `fields` list *after* that fields list has been used to know what fields to export. Meaning the fields list isn't filtered anymore, and requesting the xid on a view would blow up due to a latter assertion checking against that. Fix the filter, although a better solution might be to strip out the field upstream (in the fields list provided to the export wizard) such that users wouldn't even attempt to perform this export. An other possibility (possibly combined with the previous) could be to only strip out the export of the xid based on the absence of an ``id`` field on the model, though that's somewhat risky: technically views have no reason to be stable so a "record" could disappear or move around without the ORM being aware, leading to dangling xids. Fixes #46674 closes odoo/odoo#62993 X-original-commit: adc25bcf67438675bc9b0d55975ce733d58b4fb5 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Some actions use 'non-standard' key in the action dict, to pass extra parameters. In that situation the filtering of keys in `clean_action()` strips valuable params, in an attempt to avoid leaking internal action data. One example of this is the dynamic action definition returned by `open_yodlee_action()` in the account_yodlee module, which uses several non-standard properties. This commit alters the filtering logic in order to allow extra keys by default, as long as they're not actual fields of the action model (and therefore should not cause unintended "internal data" leaks). A warning is also added to recommend passing those extra parameters in the `context` and `params` action properties, which are explicitly designed for this, by convention. For cases where extra properties are returned and where the warning is annoying, those properties can be explicitly _allowed_ by making them virtual action fields, through a `_get_readable_fields()` override.
- Create a product with: Cost: 60.80 Quantity On Hand: 999.0 - Go to Inventory / Reporting / Inventory Report - Export as XLS The header values have too many decimals: 60739.2000000007 The root cause is `convert_to_cache` returns this value: https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333 In this case, `currency.round()` keeps the extra digits. Since the field is not stored, the useless digits are kept. A simple solution is to use `float_repr` on the non-stored float fields to make sure that doesn't happen. Another solution could be to not convert the floats to strings, but that doesn't seem intended. opw-2378895 closes odoo/odoo#62260 X-original-commit: 2ebcbb16f113dee1416097b7a52f8068a40a34cf Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Doesn't seem used since it's been broken forever on python 3: base64.b64encode returns binary data, on which json.dumps chokes. Still, removing the endpoint on old stables seems a bit brutal so just fix it. closes odoo/odoo#56647 X-original-commit: 7fc9bc28986d69184df5a4fdeefbe09e4b39b8f0 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
/web/action/load is the public controller that Should be used by the webclient to fetch actions _for_xml_id is the default access method on actions that implements fields filtering to avoid leaking server action code or other information not needed by the webclient Implementing whitelist of fields that can be access per model