Saturday, March 23, 2024
7 changes · saas-17.1
Miscellaneous changes
Before this commit, when using a shipping method with the variable weight*volume for price computation, the price was growing with the square of the ordered quantities. This is because both volume and weight were multiplied by the quantity, before being multiplied with each other in the next step. This commit fixes the issue by introducing the variable weight*volume at the beginning of the computation. In order not to break anything in stable, the new variable is added as a kwarg to the us
Original PR description
Before this commit, when using a shipping method with the variable weight*volume for price computation, the price was growing with the square of the ordered quantities. This is because both volume and weight were multiplied by the quantity, before being multiplied with each other in the next step. This commit fixes the issue by introducing the variable weight*volume at the beginning of the computation. In order not to break anything in stable, the new variable is added as a kwarg to the useful methods. OPW-3802315 Forward-Port-Of: odoo/odoo#158899 Forward-Port-Of: odoo/odoo#158767
## Issue: - When adding tasks to a contact using Studio and attempting to set a task's project to a project linked to a Sales Order (SO), we encounter the following error: "TypeError: 'NewId' object is not iterable." ## Steps To Reproduce: - In a contact form open Studio and add a O2M field Customer (Task) - Create a new task in the O2M and set the Project to a project related to a SO. - Notice Traceback Error "TypeError: 'NewId' object is not iterable" ## Solution: - The issue arises
Original PR description
## Issue: - When adding tasks to a contact using Studio and attempting to set a task's project to a project linked to a Sales Order (SO), we encounter the following error: "TypeError: 'NewId' object…
## Issue:
- When adding tasks to a contact using Studio and attempting to set a task's project to a project linked to a Sales Order (SO), we encounter the following error: "TypeError: 'NewId' object is not iterable."
## Steps To Reproduce:
- In a contact form open Studio and add a O2M field Customer (Task)
- Create a new task in the O2M and set the Project to a project related to a SO.
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
## Solution:
- The issue arises in the search domain of [_get_last_sol_of_customer](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/addons/sale_timesheet/models/project.py#L603), where the domain is ('order_partner_id', 'child_of', self.partner_id.commercial_partner_id.id), and the type of `self.partner_id.commercial_partner_id.id` is `NewId` since the partner is being edited to add a task.
- This action triggers the [parse](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/odoo/osv/expression.py#L805) and [to_ids](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/odoo/osv/expression.py#L847) methods with a value type of `NewId`. thus the error.
- The operator child_of deals with a list of ids, and the ids property refer to the record's origin ids. to resolve this, replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#157318Imagine the following situation: an automated action A is triggered when some stored computed field F has a certain value. When a record is created and no value is given for field F, then the automated action A may be run twice: once when evaluating A's domain forces the computation of F, and once again because A's domain is satisfied. The implementation already uses context flags to reflect which automated actions have already been run, in order to avoid automated actions to be run re
Original PR description
Imagine the following situation: an automated action A is triggered when some stored computed field F has a certain value. When a record is created and no value is given for field F, then the automated action A may be run twice: once when evaluating A's domain forces the computation of F, and once again because A's domain is satisfied. The implementation already uses context flags to reflect which automated actions have already been run, in order to avoid automated actions to be run recursively. The fix consists in enabling those context flags to be shared among the evaluation of the domain and processing of the automated actions. opw-[3731182] Forward-Port-Of: odoo/odoo#157272
*: website, website_twitter This commit introduces an update to the Font Awesome library, specifically replacing the X/Twitter icon with its new design. It also involves adjustments to a few images and SVG files to incorporate the updated X/Twitter logo. Technical note: It updates an existing file, originally modified for the addition of the TikTok icon, which was not available in Font Awesome 4. Related to: https://github.com/odoo/enterprise/pull/53644 task-3463530 --- I con
Original PR description
*: website, website_twitter This commit introduces an update to the Font Awesome library, specifically replacing the X/Twitter icon with its new design. It also involves adjustments to a few images and SVG files to incorporate the updated X/Twitter logo. Technical note: It updates an existing file, originally modified for the addition of the TikTok icon, which was not available in Font Awesome 4. Related to: https://github.com/odoo/enterprise/pull/53644 task-3463530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158586 Forward-Port-Of: odoo/odoo#148126
Currently, log level error mesage occur when`ValueError` is catched by line [1]. This commit changes 'logger.error' to 'logger.warning' with filename to log message instead of error since this is not an actual error of the codebase. [1]-https://github.com/odoo/odoo/blob/3932c46f914c40be4b0629771d1981cdf289df26/addons/web/controllers/binary.py#L131 sentry-4657682601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: o
Original PR description
Currently, log level error mesage occur when`ValueError` is catched by line [1]. This commit changes 'logger.error' to 'logger.warning' with filename to log message instead of error since this is not an actual error of the codebase. [1]-https://github.com/odoo/odoo/blob/3932c46f914c40be4b0629771d1981cdf289df26/addons/web/controllers/binary.py#L131 sentry-4657682601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158342
Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key). Previously, the field `image_1920` was used which has two issues: 1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be use
Original PR description
Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128`…
Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key). Previously, the field `image_1920` was used which has two issues: 1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be used. 2.) `image_1920` is a computed, non-stored, field. This has the implication that the image will be processed, thus consuming more memory (even leading to a MemoryError on the customer's DB). This happens like so: a.) `_compute_image_1920` is called, which sets a value into `record.image_1920`. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/addons/product/models/product_product.py#L157 b.) Eventually `_image_process` is called, which performs memory intensive computations on the image. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/odoo/fields.py#L2550 So this can be avoided by implementing this commit, which will check the stored, non-computed fields instead. Memory benchmarks for allocations by `_get_self_order_data`: Done on customer DB with 1340 product.products, with a total of 776 images between them. Before commit: 1638.4 MiB + server memory limit reached After commit: 29.7 MiB total Total improvement of 55x less memory usage Current behavior before PR: Server memory limit reached when loading pos kiosk with many product images in filestore Desired behavior after PR is merged: Use much less memory. opw-3809503 Forward-Port-Of: odoo/odoo#157900
*: website_twitter_wall This commit involves adjustments to a few images and SVG files to incorporate the new X (previously called Twitter) logo. related to: https://github.com/odoo/odoo/pull/148126 task-3463530 Forward-Port-Of: odoo/enterprise#59147 Forward-Port-Of: odoo/enterprise#53644
Original PR description
*: website_twitter_wall This commit involves adjustments to a few images and SVG files to incorporate the new X (previously called Twitter) logo. related to: https://github.com/odoo/odoo/pull/148126 task-3463530 Forward-Port-Of: odoo/enterprise#59147 Forward-Port-Of: odoo/enterprise#53644