Odoo Changelog — 2024-03-23

Saturday, March 23, 2024

5 changes · saas-17.2

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_br: fix pix qr code without amount

Coresaas-17.2l10n_brl10n_test_pos_qr_paymentMEDIUM

This fix allows Brazilian Pix QR codes to be generated even when no payment amount is set. It supports offline point-of-sale use cases where the final amount may not be available when the QR code is created.

Original PR description

Since this commit we support the QR code without amount To be used in the POS when the POS is offline.

Introduced by: https://github.com/odoo/odoo/pull/148803/commits/f286e2c0473c568991171ef8c0b2dbb9871d2f2e

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#Brazil#Pix#QR code#POS#offline payments

Other(4)

Miscellaneous changes

[FW][FIX] pos_self_order: use stored fields to check if product "has_image"

PR #158940

Coresaas-17.2pos_self_order

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` 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

[FW][FIX] account_peppol: handle participant not ready error

PR #158893

Coresaas-17.2account_peppol

Original PR description

### [FIX] account_peppol: handle participant not ready error If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an…

### [FIX] account_peppol: handle participant not ready error

If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an error. On the client side a user sees a traceback, because we're trying to retrieve a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid']`. That's because we treat that error in the try block and then proceed to the else block because technically there was no exception. This commit moves that error handling to `else` block so that such invoices get the proper error messages.

### [FIX] account_peppol: mock external request

Now that we check whether a participant exists on Peppol network first when they register, we should also mock that request. Currently, since that request is not mocked, all peppol tests are skipped.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#158546
Forward-Port-Of: odoo/odoo#154926

[FW][FIX] base_automation: double trigger caused by computed field

PR #158854

Coresaas-17.2base_automationtest_base_automation

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 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

[FW][FIX] sale_timesheet: sale_timesheet: resolve NewId error on SO linked tasks

PR #158859

Coresaas-17.2sale_timesheet

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 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#157318

Since this commit we support the QR code without amount To be used in the POS when the POS is offline. Introduced by: https://github.com/odoo/odoo/pull/148803/commits/f286e2c0473c568991171ef8c0b2dbb9871d2f2e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

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

### [FIX] account_peppol: handle participant not ready error If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an error. On the client side a user sees a traceback, because we're trying to retrieve a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid']`. That's because we treat that error in the try block and then proceed to the else block because technically there was no exception. This commit moves that error handling to `else` block so that such invoices get the proper error messages. ### [FIX] account_peppol: mock external request Now that we check whether a participant exists on Peppol network first when they register, we should also mock that request. Currently, since that request is not mocked, all peppol tests are skipped. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158546 Forward-Port-Of: odoo/odoo#154926

## 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#157318