Daily updates from Odoo
Friday, November 14, 2025
14 changes · 17.0
Resolved issues and error corrections
This fix restores placeholder text in the Related Company field and similar partner autocomplete fields. It helps users understand what information is expected when creating or editing contacts, improving the clarity of the form.
Original PR description
**Issue:** Fields using the res_partner_many2one widget with a placeholder do not display the placeholder text. **Steps to reproduce:** 1. Install `contacts` module 2. Go to Contacts 3. Create new 'Individual' contact 4. Notice just below the name, Related Company field placeholder is not visible. **Cause:** Props are not passed correctly in PartnerAutoComplete component **Solution:** Use the correct prop reference (props.placeholder) when passing the placeholder to the PartnerAutoComplete component, ensuring it is properly rendered. opw-5153125
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.
The debit note wizard now keeps the correct default document type instead of replacing it with the first invoice-related one. This helps users create debit notes with the right prefilled document type and avoids confusion during document generation.
Original PR description
Restores code from v16 to define a default document type for debit notes on records with debit_origin_id. Previously, when using the wizard to generate a debit note, the default document type (related to debit notes) was being overwritten by the first document type associated with invoices. Although this behavior will be removed in v17, this fix is necessary to prevent overwriting the default value for now. Note: It's still possible to use the document type for invoices. Therefore, the change only affects the computation of the default value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents a revoked portal contact from being incorrectly reused as the default public user for a website in the same company. It helps avoid accidental exposure of interactions or orders to the wrong person and keeps website behavior aligned with the intended anonymous user.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
opw-4760550
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis 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 quantity-based quality checks from being requested too early when the related stock move line does not yet have a lot or serial number. It reduces confusion for users and ensures the check appears only when the required traceability information is available.
Original PR description
This commit make sure the quality checks 'by quantity' are not asked to be filled in in case the related move line is not completed yet by a serial number or lot. Task : 4716252
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