Daily updates from Odoo
Thursday, June 5, 2025
16 changes · master
Resolved issues and error corrections
Spreadsheet cell comment windows now use the right reply box layout, preventing duplicate send buttons and confusing keyboard shortcuts. This makes commenting on spreadsheet cells more consistent and easier to use.
Original PR description
## Description This PR changes the props passed to the composer by avoiding the use of `mode: 'extended'` when `inChatWindow: true` is set. That combination caused UI inconsistencies such as duplicate send buttons and conflicting keyboard shortcuts. The chat window is meant to use the compact composer/normal configuration for proper styling and expected behavior. Task: [4727169](https://www.odoo.com/odoo/project/2328/tasks/4727169)
This update adjusts automated WhatsApp-related tests to match a recent change where channel access settings moved into a popup menu. It helps keep quality checks reliable without changing the user-facing WhatsApp features themselves.
Original PR description
Purpose of this commit: After [1], the channel access setting have been add inside into a popup menu, adapt the conflicting testcases accordingly. [1] odoo/odoo#178313 task-4100138
Miscellaneous changes
Before this commit: ------------------ - The preparation ticket displayed DUPLICATA on every print, regardless of whether it was a reprint or not. After this commit: -------------------- - DUPLICATA is now printed only when the preparation ticket is a reprint, avoiding confusion during regular printing. Task: 4789682 Related PR - https://github.com/odoo/odoo/pull/209640 Forward-Port-Of: odoo/enterprise#86866 Forward-Port-Of: odoo/enterprise#85740
Original PR description
Before this commit: ------------------ - The preparation ticket displayed DUPLICATA on every print, regardless of whether it was a reprint or not. After this commit: -------------------- - DUPLICATA is now printed only when the preparation ticket is a reprint, avoiding confusion during regular printing. Task: 4789682 Related PR - https://github.com/odoo/odoo/pull/209640 Forward-Port-Of: odoo/enterprise#86866 Forward-Port-Of: odoo/enterprise#85740
This commit removes the translate functionality from the chatgpt plugin in the ai module. That is done to effectively decouple the two functionalities since they are independent in their implementations and their use. The translate functionality is added back in the html_editor module as a separate editor plugin. Community PR: https://github.com/odoo/odoo/pull/209931 Forward-Port-Of: odoo/enterprise#85506
Original PR description
This commit removes the translate functionality from the chatgpt plugin in the ai module. That is done to effectively decouple the two functionalities since they are independent in their implementations and their use. The translate functionality is added back in the html_editor module as a separate editor plugin. Community PR: https://github.com/odoo/odoo/pull/209931 Forward-Port-Of: odoo/enterprise#85506
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - partner: EU partner - Invoice Date: 01 Dec 2024 - Accounting Date: 01 Jan 2025 - Amount: 1000 - Confirm and create the credit note dated 02 Jan 2025 - Check Mod 349 Tax Report for Jan 2025 Issue: In the Invoices section we can see the full invoice amount (1000) but nothing about the refund This occurs because we use the invoice date to decide if we consider the move amount for the current se
Original PR description
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - partner: EU partner - Invoice Date: 01 Dec 2024 - Accounting Date: 01 Jan 2025 - Amount: 1000 - Confirm and create the credit note dated 02 Jan 2025 - Check Mod 349 Tax Report for Jan 2025 Issue: In the Invoices section we can see the full invoice amount (1000) but nothing about the refund This occurs because we use the invoice date to decide if we consider the move amount for the current section and not the accounting date opw-4718611 Forward-Port-Of: odoo/enterprise#86839 Forward-Port-Of: odoo/enterprise#85479
The last section of l10n_lu_reports's annual tax report makes use of a custom component. Due to the changes introduced in https://github.com/odoo/enterprise/commit/b4e146e34561f9d0411fcfa4cc9faf9b66dcffb0, the component registration was made on the wrong module. This "module" parameter of registerCustomComponent is too error prone, and will create errors in forward-ports; let's get rid of it, and simply make sure we use unique class names on components (by prefixing them L10nXX in localizations)
Original PR description
The last section of l10n_lu_reports's annual tax report makes use of a custom component. Due to the changes introduced in https://github.com/odoo/enterprise/commit/b4e146e34561f9d0411fcfa4cc9faf9b66dcffb0, the component registration was made on the wrong module. This "module" parameter of registerCustomComponent is too error prone, and will create errors in forward-ports; let's get rid of it, and simply make sure we use unique class names on components (by prefixing them L10nXX in localizations). Forward-Port-Of: odoo/enterprise#86952 Forward-Port-Of: odoo/enterprise#86333
The XML already reports **PesoBrutoVehicular** in metric tonnes, as required by the Carta Porte complement. However, the PDF layout labelled the value as **kg**. * Updated QWeb template to display the unit `t`. Legal basis ----------- * Complemento Carta Porte 3.1 – Instructivo de llenado: “Peso Bruto Vehicular… atributo requerido para indicar **en toneladas** el peso bruto vehicular permitido… de acuerdo con la NOM-SCT-012-2017”. :contentReference[oaicite:0]{index=0} Forward-Port-Of:
Original PR description
The XML already reports **PesoBrutoVehicular** in metric tonnes, as required by the Carta Porte complement.
However, the PDF layout labelled the value as **kg**.
* Updated QWeb template to display the unit `t`.
Legal basis
-----------
* Complemento Carta Porte 3.1 – Instructivo de llenado: “Peso Bruto Vehicular… atributo requerido para indicar **en toneladas** el peso bruto vehicular permitido… de acuerdo con la NOM-SCT-012-2017”. :contentReference[oaicite:0]{index=0}
Forward-Port-Of: odoo/enterprise#85798Prior to this commit, passing below the medium bootstrap threshold (992px) in the Knowledge form view would make it so the body width would fit its content instead of taking all the available space. The issue was introduced by the removal of some media queries in [this commit]. [this commit]: https://github.com/odoo/enterprise/commit/3f58d0e6f8f9958a3fd6fbba47d11c3d376cd51f task-4836314 Forward-Port-Of: odoo/enterprise#86700
Original PR description
Prior to this commit, passing below the medium bootstrap threshold (992px) in the Knowledge form view would make it so the body width would fit its content instead of taking all the available space. The issue was introduced by the removal of some media queries in [this commit]. [this commit]: https://github.com/odoo/enterprise/commit/3f58d0e6f8f9958a3fd6fbba47d11c3d376cd51f task-4836314 Forward-Port-Of: odoo/enterprise#86700
If account and account_accountant are installed but not accountant the test test_change_payment_state_valid will fail This occurs because the valid payment states for batch payments change when accountant is installed runbot-226305 Forward-Port-Of: odoo/enterprise#86821
Original PR description
If account and account_accountant are installed but not accountant the test test_change_payment_state_valid will fail This occurs because the valid payment states for batch payments change when accountant is installed runbot-226305 Forward-Port-Of: odoo/enterprise#86821
to reproduce: ============= - enable timesheet for a helpdesk team - create 5 tickets with 10 minutes each - on list view of tickets, select these tickets -> total spent time is 51 minutes instead of 50 minutes Problem: ======== time is represented as float, when computing the total time spent, we round the float value to 2 decimal places, which can lead to loss of precision. for example 10 minutes is represented as 0.16666666666666666 hours, and when we round it to 2 decimal places,
Original PR description
to reproduce: ============= - enable timesheet for a helpdesk team - create 5 tickets with 10 minutes each - on list view of tickets, select these tickets -> total spent time is 51 minutes instead of 50 minutes Problem: ======== time is represented as float, when computing the total time spent, we round the float value to 2 decimal places, which can lead to loss of precision. for example 10 minutes is represented as 0.16666666666666666 hours, and when we round it to 2 decimal places, we get 0.17 hours, which is 10.2 minutes. when we sum up 5 tickets, we get 0.85 hours, which is 51 minutes. Solution: ========= we don't round the float value to 2 decimal places, and we let the front handle the display of the time in the correct format. opw-4560872 Forward-Port-Of: odoo/enterprise#86988 Forward-Port-Of: odoo/enterprise#86423
https://github.com/odoo/odoo/pull/212452 Forward-Port-Of: odoo/enterprise#86732
Original PR description
https://github.com/odoo/odoo/pull/212452 Forward-Port-Of: odoo/enterprise#86732
- add a search filter on returns using the name - Increase slightly the Return title to make it more visible - Make the deadline black instead of blue to prevent user clicking on it. - Change wording from "Failed" to "Pending" for returns checks. task-4825767 Forward-Port-Of: odoo/enterprise#86544
Original PR description
- add a search filter on returns using the name - Increase slightly the Return title to make it more visible - Make the deadline black instead of blue to prevent user clicking on it. - Change wording from "Failed" to "Pending" for returns checks. task-4825767 Forward-Port-Of: odoo/enterprise#86544
The recognition entry for corporate tax was incorrect as it was crediting the expense while debiting the liability. This fixes the entry to: Debit: Tax Report Counter Part Account Credit: Liabilities Account for Tax Report Task ID: 4808001 Forward-Port-Of: odoo/enterprise#86315
Original PR description
The recognition entry for corporate tax was incorrect as it was crediting the expense while debiting the liability. This fixes the entry to: Debit: Tax Report Counter Part Account Credit: Liabilities Account for Tax Report Task ID: 4808001 Forward-Port-Of: odoo/enterprise#86315
Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand. ### Steps to reproduce: - Create a storable product. Put 5 units in stock. - Create a delivery order for 5 units and mark as to do. - Go to the barcode app and edit your delivery order. - Click on the pencil and set a qty of 1 > Confirm - Click back on the pencil and reset the quantity to 0 > confirm #### > On the picking, the demand of the line was edited from 5 to 1. ### Cause
Original PR description
Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand. ### Steps to reproduce: - Create a storable product. Put 5 units in stock. - Create a delivery…
Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand. ### Steps to reproduce: - Create a storable product. Put 5 units in stock. - Create a delivery order for 5 units and mark as to do. - Go to the barcode app and edit your delivery order. - Click on the pencil and set a qty of 1 > Confirm - Click back on the pencil and reset the quantity to 0 > confirm #### > On the picking, the demand of the line was edited from 5 to 1. ### Cause of the issue: Editing the quantity of a move line from the barcode actually updates the qty_done of the move line which updates both the quantity and the picked status of the move line in the backend via the `_inverse_qty_done`: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/models/stock_move_line.py#L58-L62 Initially, the quantity of the move line was 5 and hence the demand of the line in the barcode was displayed as 5: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L119-L121 The first time you edit the line, you will actually change its quantity to 1 and set it as picked. Once the line state refreshes in the barcode it will then keep the same demand of 5 as it will then be based on the previous demand of the line (since the qty of the move line is set and the qty done is positive): https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 However, the next time you update the line the `_inverse_qty_done` will leave the quantity of the move line at 1 but will also unpick it. Then, and since the `qty_done` was set to 0, it will update the demand of the barcode line because of these same lines: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 ### Fix: Prior to Commit 3af3e00aabecde8b811ac2cbab397f982721f164 the quantity was updated as well as the picked state even when the qty_done was set to 0, so that this issue would not occur as the null quantity would make us keep the demand of barcode line after edition. However, the problem was that this would update the reserved quantity of the move and hence the barcode app demand once you leave the barcode app because of the `split_uncompleted_moves`. However, in the present use case, that same method can save us because if the move is picked and its quantity is null when you exit the barcode app, it will be rereversed. opw-4700996 Forward-Port-Of: odoo/enterprise#86334 Forward-Port-Of: odoo/enterprise#83623
Issue: When we create more than one event with different status for the same appointment type, the allowed events container is only updated with the most recently created event. The Purpose of this PR: To update the count of event ids for the same appointment type. Steps to reproduce on runbot: create multiple events for the same appointment type. shuffle the events around return to the appointments menu and see that the upcoming meetings count does not match opw-4831384 Forward-Po
Original PR description
Issue: When we create more than one event with different status for the same appointment type, the allowed events container is only updated with the most recently created event. The Purpose of this PR: To update the count of event ids for the same appointment type. Steps to reproduce on runbot: create multiple events for the same appointment type. shuffle the events around return to the appointments menu and see that the upcoming meetings count does not match opw-4831384 Forward-Port-Of: odoo/enterprise#86844
Steps to Reproduce: ================== -Install the l10n_mx_edi module. -Switch to the ESCUELA KEMPER URGATE company. -Create a customer invoice and generate the CFDI. -Change the customer’s language to Spanish (MX). -Register a payment for the invoice. -Go to the related payment record. -Force the CFDI generation. -Print the CFDI. Cause: ====== Some keys will not be translated due to missing translation values. Forward-Port-Of: odoo/enterprise#85981
Original PR description
Steps to Reproduce: ================== -Install the l10n_mx_edi module. -Switch to the ESCUELA KEMPER URGATE company. -Create a customer invoice and generate the CFDI. -Change the customer’s language to Spanish (MX). -Register a payment for the invoice. -Go to the related payment record. -Force the CFDI generation. -Print the CFDI. Cause: ====== Some keys will not be translated due to missing translation values. Forward-Port-Of: odoo/enterprise#85981