Friday, November 14, 2025
12 changes · 17.0
Enhancements to existing features
The FEC import process has been optimized to avoid loading unnecessary partner data into memory. This reduces the risk of import failures on databases with a very large number of partners and makes the import more reliable.
Original PR description
### Description: When importing an FEC, Odoo will fetch all the partners to link the new imported records to the existing partners. The issue is that it triggers the prefetching of all the fields of the partners (304k partners in their case), causing a memory error. To avoid that, we can just fetch the field that we need (e.g. "name" and "ref"). ### Reference: opw-5153555
Invoices using Swiss QR codes now include creditor and debtor addresses in a structured format. This update aligns the QR code content with legal requirements, reducing the risk of payment issues or non-compliant invoices.
Original PR description
This commit changes the creditor's and debtor's address to a structured format inside the CH QR-code in invoices. The address type was changed from "K" to "S" due to legal requirements. Task [link](https://www.odoo.com/odoo/project.task/5149417) task-5149417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The floor plan now only shows booking notifications when they match the booking setup selected in the point of sale. This avoids confusing temporary bookings that could appear and then disappear after a refresh, and it also clears the booking setting automatically when table booking is turned off.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/my-tasks/5005216) Enterprise v18.0: [#93636](https://github.com/odoo/enterprise/pull/93636) --- **Before:** If no appointment type is specified in the POS config and a table is booked via the website, the floor plan is notified of a new booking because the resource used is one of the POS config resources. However, if the page is refreshed, the booking disappears since no appointment type is defined in the POS config **After:** The floor plan is notified of a new booking only if the appointment type of the booking matches the one specified in the POS config. If no appointment type is set in the POS config, no booking notifications are sent. Additionally, when the "Table Booking" field is unchecked in the POS config, the appointment type is automatically unset.
This change fixes an issue where some incoming emails could not be read if they used the encoding label "cp-850". Odoo now recognizes this label as a valid variant, so these messages are processed correctly instead of causing an error.
Original PR description
While investigating a few support tickets related to how the l10n_cl override the fetch mail methods, we noticed a more general issue: As of now, the payload parsing business logic of Odoo can't…
While investigating a few support tickets related to how the l10n_cl override the fetch mail methods, we noticed a more general issue:
As of now, the payload parsing business logic of Odoo can't handle emails encoding parts with `charset=cp-850`.
This is due to the fact that `cp-850` is not a accepted/standard encoding alias for cp850 charsets in python's `encoding` library.
Whether or not a mail stack should generate mail using `charset=cp-850` or not, we this fix aims at pro-actively declaring `cp-850` as a valid alias for cp850, so that implicitly the email CPython library can correctly decode the payloads in emails.
### Before this bug:
Sending a mail using `charset=cp-850` would generate a traceback.
Example:
```
From: Sender Name <sender@example.com>
To: Recipient Name <odooalias@example.com>
Subject: Test Email with CP-850 Encoding
Date: Thu, 13 Nov 2025 12:00:00 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_4987654321-00000000"
This is a multi-part message in MIME format.
------------=_4987654321-00000000
Content-Type: text/plain; charset=cp-850
Content-Transfer-Encoding: quoted-printable
Hallo, dit is een test met een =82 speciale letter.
=
------------=_4987654321-00000000--
```
Would generate:
```
File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1398, in message_process
msg_dict = self.message_parse(message, save_original=save_original)
File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1792, in message_parse
msg_dict.update(self._message_parse_extract_payload(message, msg_dict, save_original=save_original))
File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1592, in _message_parse_extract_payload
content = part.get_content()
File "/home/odoo/miniconda3/lib/python3.10/email/message.py", line 1096, in get_content
return content_manager.get_content(self, *args, **kw)
File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 22, in get_content
return self.get_handlers[maintype](msg, *args, **kw)
File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 67, in get_text_content
return content.decode(charset, errors=errors)
LookupError: unknown encoding: cp-850
```
### After fix:
`content = part.get_content()` correctly handles the `cp-850` alias
OPW-5171501
OPW-5247486
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prGantt items can no longer be dropped onto rows that are grouped by a field users should not edit. This prevents accidental updates to protected values during planning, avoiding unexpected changes in work orders and similar records.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366
This change makes analytic line creation use the company’s currency rules instead of the journal item’s currency. It prevents small calculation differences when currencies use different rounding settings, helping ensure more accurate accounting analytics.
Original PR description
Analytic line values are determined by the balance of a journal item, not their amount_currency. https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/models/account_move_line.py#L3230-L3237 However, the journal item's currency is referenced when creating an analytic line. This can cause discrepancies when the journal item's currency has a different rounding factor (`rounding`). [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5171681) opw-5171681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings back contact information in the Swiss payroll transmission employee view. It matters because the missing details are needed to keep employee records complete and support correct payroll reporting.
Original PR description
task-5248986
This fix prevents the VoIP system from trying to reconnect twice when a user leaves the page. It avoids a registration conflict that could cause errors during page unload and helps make call handling more reliable.
Original PR description
On page unload, two conflicting things happen: - A REGISTER request with expires=0 is sent to invalidate the registration - The WebSocket disconnects, triggering the reconnection mechanism that attempts to reissue a registration These two concurrent and conflicting REGISTER requests result in the following error: > RequestPendingError: REGISTER request already in progress, waiting for final response This commit prevents the reconnection mechanism from occurring in the event of a "natural" disconnection, such as one triggered by a page unload. This way, the two conflicting REGISTER requests aren't sent on page unload. [Task-5261940](https://www.odoo.com/odoo/project/5778/tasks/5261940)
This update makes WebSocket connections close more reliably by correctly tracking multiple pending timeouts and waiting properly for the other side to respond. It also ensures stalled connections are forcefully ended if the shutdown handshake never completes, reducing the risk of lingering connections and missed disconnects.
Original PR description
This PR fixes several issues with WebSocket timeouts: - Waiting for more than one response was not handled properly, resulting in missed timeouts. - The closing handshake did not strictly follow the RFC when initiated on the server side (it closed without waiting for the other peer). - Close timeouts were not enforced (the connection was not terminated when the other peer did not respond to the close frame).
This change prevents regular users from hitting an access error when creating a Global Invoice in the Mexican electronic invoicing flow. It ensures the needed attachment updates can be completed smoothly, so invoice processing works for demo and other non-admin users.
Original PR description
## Issue: When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised: `Sorry, you are not allowed to access this document` ## Cause: This commit change the attachment creation to use the SUPERUSER: https://github.com/odoo/enterprise/pull/95197 However, updating `attachment.res_id` then required `base.group_system` access rights, preventing regular users from modifying the attachment As a result, non-admin users (like demo) triggered an access error during Global Invoice creation ## Steps to reproduce: - Switch to the MX company - Create a product with an UNSPSC Category (Accounting Tab) - Create and Confirm an Invoice for the product (enable CFDI to public) - Connect as Demo - Go in Accounting > Customers > Invoices - Toggle the last created invoice checkbox - Actions > Create Global Invoice - Before the fix, the Access Error is displayed - Check in the invoice Chatter for the Global CFDI document creation success opw-5181925
Sales orders in Portugal now automatically use the correct tax position based on the warehouse location, instead of relying on manual selection. This reduces the risk of invoicing errors and helps ensure VAT is applied according to place-of-supply rules.
Original PR description
Implements automation to correctly set the sales order fiscal position based on the warehouse, ensuring compliance with "place of supply" VAT rules. Problem: - The VAT rate must be determined by the supply location (warehouse), not the customer's delivery address. - Manually selecting the fiscal position on every sales order is slow and highly prone to user error, leading to incorrect invoicing. task-5088046 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes hidden newline characters from fields used in Swiss QR codes. It helps ensure the codes are formatted correctly and accepted by banks or payment systems without rejection.
Original PR description
Swiss QR codes have required information for each line of the QR code. Newline characters present in a field's content shift the content to a different line than intended, causing the QR code to be rejected. This commit removes newline characters from the field elements and alters a unit test to check if this issue occurs again. opw-5095997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr