Daily updates from Odoo
Saturday, November 15, 2025
30 changes
6 changes
Resolved issues and error corrections
When an employee time off allocation is switched from Accrual back to Regular, the previously chosen accrual plan is now cleared properly. This prevents hidden leftover settings from being saved and keeps allocation records consistent.
Original PR description
When creating a new allocation, selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend, Flush accrual_plan_id when changing the…
When creating a new allocation, selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend, Flush accrual_plan_id when changing the allocation type. ### **Steps to reproduce:** 1. Create a test database (version 17 or later). 2. Install the `hr_holidays` module. 3. In the Time Off module, navigate to Allocations. 4. Create a new allocation. 5. Select "Accrual Allocation" and assign an accrual plan. 6. Change the allocation type back to "Regular Allocation" and save. 7. Verify the accrual plan is registered in the backend. **Note:** The accrual_plan_id field is displayed for visibility. **Before Fix:** <img width="1897" height="610" alt="before_allocation" src="https://github.com/user-attachments/assets/357c6c1d-3d57-4d2e-bf23-1cf260897aa1" /> <img width="1894" height="477" alt="before" src="https://github.com/user-attachments/assets/af193cd9-2e61-4fa9-8488-927e899ca574" /> ```python3 test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 18; id | private_name | allocation_type | accrual_plan_id ----+-------------------+-----------------+----------------- 18 | Before allocation | regular | 1 (1 row) ``` **After Fix:** <img width="1898" height="555" alt="after_allocation" src="https://github.com/user-attachments/assets/60702c72-2e16-4a5f-9b48-213f3c845437" /> <img width="1900" height="535" alt="after" src="https://github.com/user-attachments/assets/15cb27fa-f54b-4e98-94c6-77ae92934c9f" /> ```python3 test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 19; id | private_name | allocation_type | accrual_plan_id ----+------------------+-----------------+----------------- 19 | after allocation | regular | (1 row) ``` 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 Forward-Port-Of: odoo/odoo#235568 Forward-Port-Of: odoo/odoo#231253
Odoo now correctly reads emails that use the cp-850 character encoding label, which previously could cause incoming message processing to fail. This reduces support issues and helps ensure emails from some systems are imported without errors.
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-pr
Forward-Port-Of: odoo/odoo#235529Delivery slips now show separate lines for the same product when it was received in different package sizes. This fixes reports that previously combined these items incorrectly, making delivery documents clearer and more accurate.
Original PR description
Before this commit: ------------------------- When printing the delivery slip of a Purchase Order containing products with different packaging units of measure (UoM), all units of the same product…
Before this commit:
-------------------------
When printing the delivery slip of a Purchase Order containing products with
different packaging units of measure (UoM), all units of the same product were
aggregated into a single line, regardless of their packaging type.
Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Create Purchase Order.
3. Add 3 move lines for the same product, each with a different packaging UOM:
- Product 1 - Pack of 2
- Product 1 - Pack of 4
- Product 1 - Pack of 6
4. Confirm the PO and click Receive.
5. Validate the receipt.
6. Go to Actions → Print → Delivery Slip.
Cause of the issue
-------------------------
The aggregation logic in _get_aggregated_properties grouped move lines only by
product, ignoring differences in packaging UoM. As a result, product lines with
different packaging types were incorrectly merged into a single line.
After this commit:
-----------------------
- Delivery slips now correctly separate product lines by packaging UoM and move
lines for the same product but with different packaging are displayed
individually.
- This provides a clearer and more accurate delivery report.
Task Id: 4879373
Forward-Port-Of: odoo/odoo#227211This change fixes an error that could appear when users click "Create and Enrich Partner." The system was passing a company record instead of its ID, which could stop the partner creation flow; now it uses the correct value so the process completes normally.
Original PR description
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button. **Error:** `ProgrammingError: can't adapt type 'res.partner'` This error occurs when the user clicks the…
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.
**Error:**
`ProgrammingError: can't adapt type 'res.partner'`
This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID,
when the system tries to browse the partner by this record [3], the error is raised.
This commit ensures that when writing the parent_id of the partner, the actual ID is used instead
of the record.
[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386
[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53
[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801
sentry-6831922000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235198This change makes Odoo’s websocket connection recovery more reliable when a connection is interrupted during shutdown. It ensures the system fully resets the connection state so users can reconnect cleanly instead of getting stuck in a closing state.
Original PR description
In [1], the websoket worker was updated to properly trigger disconnect/reconnecting/reconnect event when calling `_start` with a socket stuck in the closing state. Calling close will trigger a call to `_retryConnectionWithDelay` thus calling `_start` again. However, we need to clear the websocket as well otherwise it will still be in the closing state, preventing reconnect. [1]: https://github.com/odoo/odoo/pull/235623 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 Forward-Port-Of: odoo/odoo#235803
This update corrects how the company identification is written in NACHA payment files. It now follows the required formatting rules, helping avoid rejected or invalid bank files.
Original PR description
According to https://achdevguide.nacha.org/ach-file-overview: - An alphanumeric field must be left-justified and post-padded with spaces. - A numeric field must be unsigned, right-justified and pre-padded with zeros. The Company Identification being an alphanumeric value (see https://achdevguide.nacha.org/ach-file-details), it should be left-justified and post-padded with spaces even in the type 8 record, like it is actually in the type 5 record. opw-5048564 Forward-Port-Of: odoo/enterprise#99469 Forward-Port-Of: odoo/enterprise#98922
9 changes
Enhancements to existing features
Invoices in Switzerland now place creditor and debtor addresses in a structured format inside the QR code. This update is needed to meet legal requirements and helps ensure QR payments continue to work correctly.
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 Forward-Port-Of: odoo/odoo#235845 Forward-Port-Of: odoo/odoo#232083
Resolved issues and error corrections
This update prevents an error that could happen when users saved an invoice email as a template and then tried to add an attachment. It keeps the email wizard linked to the correct document, so sending invoices remains smooth and reliable.
Original PR description
Currently, an error occurs when trying to add an attachment after saving an invoice email as a template in the `Send wizard`. **Steps to produce:** - Install the `account` module. - Create a new…
Currently, an error occurs when trying to add an attachment after saving an invoice email as a template in the `Send wizard`. **Steps to produce:** - Install the `account` module. - Create a new invoice, fill in all required details, then `confirm` and click `Send`. - Click the `three-dot (⋮)` menu and select `Save as Template`, enter a name, and save the template. - Try to add an attachment. **Error:** `AttributeError: 'account.move.send.wizard' object has no attribute '_mail_post_access'` `AttributeError: 'account.move.send.wizard' object has no attribute '_get_thread_with_access'` Root **cause:** At [1], the code sets a new `template_id` when the template is saved. This triggers `_compute_model()` at [2], which updates the model field to `account.move.send.wizard` instead of `account.move`, using the `active_model` context, causing the `error`. **Fix:** This commit ensures that after saving a mail template, the wizard retains the correct model, same as [3], and prevents the attachment upload error. [1]: https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L296 [2]: https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L244-L248 [3]: https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/mail/wizard/mail_compose_message.py#L380-L389 sentry-6987172677 Forward-Port-Of: odoo/odoo#234268
Odoo can now read incoming emails that use the cp-850 text encoding without failing. This prevents message processing errors and helps ensure mail from affected systems is imported correctly.
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-pr
Forward-Port-Of: odoo/odoo#235529This fix ensures that when a Time Off allocation is switched from an accrual-based allocation back to a regular one, the previously selected accrual plan is cleared correctly. This prevents hidden leftover settings from being saved and keeps allocation records accurate.
Original PR description
When creating a new allocation, selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend, Flush accrual_plan_id when changing the…
When creating a new allocation, selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend, Flush accrual_plan_id when changing the allocation type. ### **Steps to reproduce:** 1. Create a test database (version 17 or later). 2. Install the `hr_holidays` module. 3. In the Time Off module, navigate to Allocations. 4. Create a new allocation. 5. Select "Accrual Allocation" and assign an accrual plan. 6. Change the allocation type back to "Regular Allocation" and save. 7. Verify the accrual plan is registered in the backend. **Note:** The accrual_plan_id field is displayed for visibility. **Before Fix:** <img width="1897" height="610" alt="before_allocation" src="https://github.com/user-attachments/assets/357c6c1d-3d57-4d2e-bf23-1cf260897aa1" /> <img width="1894" height="477" alt="before" src="https://github.com/user-attachments/assets/af193cd9-2e61-4fa9-8488-927e899ca574" /> ```python3 test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 18; id | private_name | allocation_type | accrual_plan_id ----+-------------------+-----------------+----------------- 18 | Before allocation | regular | 1 (1 row) ``` **After Fix:** <img width="1898" height="555" alt="after_allocation" src="https://github.com/user-attachments/assets/60702c72-2e16-4a5f-9b48-213f3c845437" /> <img width="1900" height="535" alt="after" src="https://github.com/user-attachments/assets/15cb27fa-f54b-4e98-94c6-77ae92934c9f" /> ```python3 test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 19; id | private_name | allocation_type | accrual_plan_id ----+------------------+-----------------+----------------- 19 | after allocation | regular | (1 row) ``` 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 Forward-Port-Of: odoo/odoo#235568 Forward-Port-Of: odoo/odoo#231253
Delivery slips now show separate lines when the same product is packed in different unit types. This avoids combining distinct packages into one entry, making the printed document clearer and more accurate for receiving and shipping teams.
Original PR description
Before this commit: ------------------------- When printing the delivery slip of a Purchase Order containing products with different packaging units of measure (UoM), all units of the same product…
Before this commit:
-------------------------
When printing the delivery slip of a Purchase Order containing products with
different packaging units of measure (UoM), all units of the same product were
aggregated into a single line, regardless of their packaging type.
Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Create Purchase Order.
3. Add 3 move lines for the same product, each with a different packaging UOM:
- Product 1 - Pack of 2
- Product 1 - Pack of 4
- Product 1 - Pack of 6
4. Confirm the PO and click Receive.
5. Validate the receipt.
6. Go to Actions → Print → Delivery Slip.
Cause of the issue
-------------------------
The aggregation logic in _get_aggregated_properties grouped move lines only by
product, ignoring differences in packaging UoM. As a result, product lines with
different packaging types were incorrectly merged into a single line.
After this commit:
-----------------------
- Delivery slips now correctly separate product lines by packaging UoM and move
lines for the same product but with different packaging are displayed
individually.
- This provides a clearer and more accurate delivery report.
Task Id: 4879373
Forward-Port-Of: odoo/odoo#227211This change fixes an error that could happen when users click "Create and Enrich Partner." The system was passing the wrong kind of value when linking the new company to a contact, which could stop the process from completing; it now uses the correct company ID so partner creation works reliably.
Original PR description
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button. **Error:** `ProgrammingError: can't adapt type 'res.partner'` This error occurs when the user clicks the…
Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.
**Error:**
`ProgrammingError: can't adapt type 'res.partner'`
This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID,
when the system tries to browse the partner by this record [3], the error is raised.
This commit ensures that when writing the parent_id of the partner, the actual ID is used instead
of the record.
[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386
[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53
[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801
sentry-6831922000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235198This update fixes two problems that could interrupt website editing: saving after replacing and deleting an image, and leaving edit mode using the browser back button. It helps ensure editors can continue working normally without getting stuck or seeing errors.
Original PR description
\* : website, web_editor, html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the…
\* : website, web_editor, html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and upload an image. 4. Open the media dialog again and delete the uploaded image. 5. Click the 'Discard' button. 6. Try to save the changes. Issue: - The website gets stuck in the same position and does not allow saving. - In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`. Expected behaviour: - Saving should be allowed with a default image, that is similar to other images. This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck. Commit [2]: resolve traceback when leaving edit mode via browser Steps to reproduce: 1. Go to Website > Edit. 2. Open the snippet modal and select any snippet. 3. Press the 'Back' button in your browser. 4. A dialog will appear asking to discard changes; click 'OK'. 5. A traceback error occurs, and an empty space appears in the editor. Issue: - Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange. - Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener. - As a result, the editor is left in an unstable state, causing a traceback error. Solution: - This commit ensures the 'window' event executes before the browser event. - It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser. task-4570164 Forward-Port-Of: odoo/odoo#199193
This update makes sure the system correctly resets its websocket connection when a disconnect is only partially completed. As a result, users are more likely to reconnect reliably instead of getting stuck in an in-between connection state.
Original PR description
In [1], the websoket worker was updated to properly trigger disconnect/reconnecting/reconnect event when calling `_start` with a socket stuck in the closing state. Calling close will trigger a call to `_retryConnectionWithDelay` thus calling `_start` again. However, we need to clear the websocket as well otherwise it will still be in the closing state, preventing reconnect. [1]: https://github.com/odoo/odoo/pull/235623 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 Forward-Port-Of: odoo/odoo#235803
This update corrects how the company identification is written in NACHA payment files so it follows the required formatting rules. It helps ensure bank files are interpreted consistently and reduces the risk of payment rejections or processing issues.
Original PR description
According to https://achdevguide.nacha.org/ach-file-overview: - An alphanumeric field must be left-justified and post-padded with spaces. - A numeric field must be unsigned, right-justified and pre-padded with zeros. The Company Identification being an alphanumeric value (see https://achdevguide.nacha.org/ach-file-details), it should be left-justified and post-padded with spaces even in the type 8 record, like it is actually in the type 5 record. opw-5048564 Forward-Port-Of: odoo/enterprise#99469 Forward-Port-Of: odoo/enterprise#98922
1 change
Resolved issues and error corrections
This update corrects how the company identification is written in NACHA payment files. The value is now formatted according to the file standard, which helps ensure bank files are generated correctly and accepted reliably.
Original PR description
According to https://achdevguide.nacha.org/ach-file-overview: - An alphanumeric field must be left-justified and post-padded with spaces. - A numeric field must be unsigned, right-justified and pre-padded with zeros. The Company Identification being an alphanumeric value (see https://achdevguide.nacha.org/ach-file-details), it should be left-justified and post-padded with spaces even in the type 8 record, like it is actually in the type 5 record. opw-5048564 Forward-Port-Of: odoo/enterprise#99469 Forward-Port-Of: odoo/enterprise#98922
4 changes
Resolved issues and error corrections
Fixes an issue where the shop floor quantity edit pop-up showed the total backorder quantity instead of the amount remaining for the selected operation. This helps production teams record partial work accurately and avoid confusion during backorder processing.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739 Forward-Port-Of: odoo/enterprise#98775 Forward-Port-Of: odoo/enterprise#93599
DHL shipment submissions now round prices and weights correctly before sending them to DHL. This prevents avoidable validation failures caused by tiny decimal precision differences, helping users validate deliveries more reliably.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#99482 Forward-Port-Of: odoo/enterprise#96012
Selecting an EasyPost carrier account in delivery method setup now works without triggering an error. This helps shipping configuration proceed smoothly when users load and choose EasyPost carrier accounts.
Original PR description
**Issue** A traceback occurs whenever a carrier is selected in the EasyPost delivery method. **Steps to reproduce** 1. Install the barcode application 2. Go to Settings > Inventory > enable…
**Issue** A traceback occurs whenever a carrier is selected in the EasyPost delivery method. **Steps to reproduce** 1. Install the barcode application 2. Go to Settings > Inventory > enable "Easypost" shipping connector 3. Go to Delivery Methods -> click "New" -> choose "Easypost" as provider 4. Fill in the API keys 5. Click "Load your Easypost carrier accounts" and select a carrier → A traceback occurs **Cause** The error occurs at: https://github.com/odoo/enterprise/blob/39320569a3561f133000ded00800f705d9507ac2/delivery_easypost/static/src/components/carrier_type_selection/carrier_type_selection.js#L15 `ev` is expected to be a JSON object but is received as a string. The component extends `SelectionField`, which has been modified in [this commit](https://github.com/odoo/odoo/commit/0923409082ead5ffdf2c28f3b063fbd91ebce553): https://github.com/odoo/odoo/blob/5be6ef1ae3958a25e680f5fa30824fec57d63efe/addons/web/static/src/views/fields/selection/selection_field.xml#L9 **Solution** Adapt the `onChange` method to handle the argument type change. opw-5170833 Forward-Port-Of: odoo/enterprise#98678
Opening Indian tax returns no longer fails due to an internal data formatting issue in validation checks. The update also ensures UQC check results open the correct unit of measure records, making it easier for users to review and correct reporting data.
Original PR description
This commit fixes traceback while opening the tax return for indian company and also fixes incorrect model name for uqc check. Traceback
```py
File /usr/lib/python3.12/json/encoder.py, line 180, in default
raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type DomainAnd is not JSON serializable
```
This Traceback is due to the use of `Domain.And` in the check of uqc code from commit :-
https://github.com/odoo/enterprise/commit/5069c133def1ab9f3288fe42c9c97d192d263321
Reason for traceback
The checks uses `_get_records_action` to open the records which internally adds the `dict(self.env.context)` which does incorrect json serialization.
Also this commit replaces `uom.uom` model inplace of `account.move.line` to open uom instead of lines.
task-5267149
Forward-Port-Of: odoo/enterprise#996288 changes
Resolved issues and error corrections
This change fixes a mail processing issue where certain incoming emails could fail to open if they used the cp-850 text encoding. Odoo now recognizes this encoding variant, so affected messages can be read and processed normally instead of triggering 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-pr
Forward-Port-Of: odoo/odoo#235529When a Time Off allocation is switched from Accrual back to Regular, the linked accrual plan is now cleared properly. This prevents the system from keeping an outdated accrual setup behind the scenes and helps avoid incorrect allocation data.
Original PR description
When creating a new allocation, selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend, Flush accrual_plan_id when changing the…
When creating a new allocation, selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend, Flush accrual_plan_id when changing the allocation type. ### **Steps to reproduce:** 1. Create a test database (version 17 or later). 2. Install the `hr_holidays` module. 3. In the Time Off module, navigate to Allocations. 4. Create a new allocation. 5. Select "Accrual Allocation" and assign an accrual plan. 6. Change the allocation type back to "Regular Allocation" and save. 7. Verify the accrual plan is registered in the backend. **Note:** The accrual_plan_id field is displayed for visibility. **Before Fix:** <img width="1897" height="610" alt="before_allocation" src="https://github.com/user-attachments/assets/357c6c1d-3d57-4d2e-bf23-1cf260897aa1" /> <img width="1894" height="477" alt="before" src="https://github.com/user-attachments/assets/af193cd9-2e61-4fa9-8488-927e899ca574" /> ```python3 test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 18; id | private_name | allocation_type | accrual_plan_id ----+-------------------+-----------------+----------------- 18 | Before allocation | regular | 1 (1 row) ``` **After Fix:** <img width="1898" height="555" alt="after_allocation" src="https://github.com/user-attachments/assets/60702c72-2e16-4a5f-9b48-213f3c845437" /> <img width="1900" height="535" alt="after" src="https://github.com/user-attachments/assets/15cb27fa-f54b-4e98-94c6-77ae92934c9f" /> ```python3 test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 19; id | private_name | allocation_type | accrual_plan_id ----+------------------+-----------------+----------------- 19 | after allocation | regular | (1 row) ``` 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 Forward-Port-Of: odoo/odoo#235568 Forward-Port-Of: odoo/odoo#231253
This fix makes websocket reconnect behavior more consistent when a connection is interrupted during closing. It ensures the system fully clears the old connection state so the service can reconnect properly instead of getting stuck.
Original PR description
In [1], the websoket worker was updated to properly trigger disconnect/reconnecting/reconnect event when calling `_start` with a socket stuck in the closing state. Calling close will trigger a call to `_retryConnectionWithDelay` thus calling `_start` again. However, we need to clear the websocket as well otherwise it will still be in the closing state, preventing reconnect. [1]: https://github.com/odoo/odoo/pull/235623 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 Forward-Port-Of: odoo/odoo#235803
This update prevents a spreadsheet error from appearing in version history actions when currency settings are not fully defined. It improves stability by making sure internal data lookups do not fail outside their intended context.
Original PR description
Some getters are (too) tied with the evaluation and sometimes take the liberty to throw evaluation-related errors. This can only work if the said getter is called exclusively in the within the…
Some getters are (too) tied with the evaluation and sometimes take the liberty to throw evaluation-related errors. This can only work if the said getter is called exclusively in the within the context of the evaluation (which has a splendid try/catch statement to this effect). Issues start to appear when we start using the said getters outside the evaluation and this is what happens. Since https://github.com/odoo/o-spreadsheet/issues/6083, we call the getter `getPivotCellFromPosition` which in specific cases call `getCompanyCurrencyFormat` and the latter will throw errors when starting and RPC. However, its effect was hidden by the sortcut added in https://github.com/odoo/odoo/pull/151725. The effect could only be seen in a version history action where we did not provide a default currency to the model config. This commit fixes the symptom but not the original cause: having getters that throw and are not handled in the components life-cycle. Such getters should probably disappear in a future refactoring. Task-5187293 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 Forward-Port-Of: odoo/odoo#232985
This fix updates the way company identification numbers are written in NACHA payment files so they follow the required ACH formatting rules. It helps ensure outgoing payroll and payment files are accepted reliably by banks and payment processors.
Original PR description
According to https://achdevguide.nacha.org/ach-file-overview: - An alphanumeric field must be left-justified and post-padded with spaces. - A numeric field must be unsigned, right-justified and pre-padded with zeros. The Company Identification being an alphanumeric value (see https://achdevguide.nacha.org/ach-file-details), it should be left-justified and post-padded with spaces even in the type 8 record, like it is actually in the type 5 record. opw-5048564 Forward-Port-Of: odoo/enterprise#99469 Forward-Port-Of: odoo/enterprise#98922
Product warnings will no longer appear on sales, purchase, or stock documents when the warning feature is turned off. This keeps document behavior consistent with the user’s settings and avoids displaying messages that should be disabled.
Original PR description
Step to reproduce:
- install purchase
- go to setting -> (enable) warning
- create a new products and add purchase warning
- now disable the warning from setting
- create a PO with that product
Observation:
- warning is visible, even though we disabled the setting
Cause:
- After commit [1] , once a warning is set on a product, it is displayed on
document regardless of the warning setting.
[1]:https://github.com/odoo/odoo/commit/1e13520ca9bb18deba85110ce9362ac2adb55904
Fix:
- Fix the computes of warning message to run only,
when the warning setting is enabled
opw-5156107
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#235562
Forward-Port-Of: odoo/odoo#231393This update fixes an error that could appear when opening tax return checks for Indian companies, so users can review reports without interruptions. It also corrects a lookup issue so the system opens the right unit-of-measure records instead of showing the wrong data.
Original PR description
This commit fixes traceback while opening the tax return for indian company and also fixes incorrect model name for uqc check. Traceback
```py
File /usr/lib/python3.12/json/encoder.py, line 180, in default
raise TypeError(f'Object of type {o.__class__.__name__} '
TypeError: Object of type DomainAnd is not JSON serializable
```
This Traceback is due to the use of `Domain.And` in the check of uqc code from commit :-
https://github.com/odoo/enterprise/commit/5069c133def1ab9f3288fe42c9c97d192d263321
Reason for traceback
The checks uses `_get_records_action` to open the records which internally adds the `dict(self.env.context)` which does incorrect json serialization.
Also this commit replaces `uom.uom` model inplace of `account.move.line` to open uom instead of lines.
task-5267149This update fixes a crash that could happen when users grouped records by a property tags field and then searched within the grouped list. It ensures the grouped view stays usable and avoids unexpected errors during everyday CRM work.
Original PR description
Step to reproduce: - open crm and add a property tags field in a lead - add that tags in few leads - go to list view and group by that property tags field - search for a lead (keep groupby as it is)…
Step to reproduce:
- open crm and add a property tags field in a lead
- add that tags in few leads
- go to list view and group by that property tags field
- search for a lead (keep groupby as it is)
Observation:
- we receive a traceback
```
File "/home/odoo/odoo/codebase/odoo/saas-18.4/addons/web/models/models.py", line 396, in web_read_group
self._open_groups(
File "/home/odoo/odoo/codebase/odoo/saas-18.4/addons/web/models/models.py", line 537, in _open_groups
info_opening['value']: info_opening
TypeError: unhashable type: 'list'
```
Cause:
- `formatter_property_tags` returns a list in case of tags field.
https://github.com/odoo/odoo/blob/5186fd202373a67f56688c234fcde15cc1997721/addons/web/models/models.py#L1176
- these values are used as a key for dict in `_open_groups`, hence only hashable values are allowed; list is not hashable
https://github.com/odoo/odoo/blob/5186fd202373a67f56688c234fcde15cc1997721/addons/web/models/models.py#L536-L539
Fix:
- cast the list to tuple
opw-5188961
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2340911 change
Resolved issues and error corrections
This update automatically applies the right sales tax position for Portuguese sales orders based on the warehouse, instead of relying on the customer’s delivery address. It reduces manual work and helps prevent invoicing mistakes by aligning orders with local VAT “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 Forward-Port-Of: odoo/odoo#227994
1 change
Resolved issues and error corrections
This change corrects an accounting check so it also handles inactive companies properly. It prevents the system from grouping records incorrectly and flagging the wrong accounts when some companies are no longer active.
Original PR description
Checking only the single account.account record per company with account_type = 'equity_unaffected', but read_group was aggregating accounts with a null account.account value when inactive companies…
Checking only the single account.account record per company with account_type = 'equity_unaffected', but read_group was aggregating accounts with a null account.account value when inactive companies were involved.
**PDD output: getting this account assosiate with no comapnny at [this point](https://github.com/odoo/odoo/blob/9b5cea53493eca60f43a8f00707f7470b08ce239/addons/account/models/account_account.py#L35)**
```python
2025-11-15 10:10:12,627 24 [1;32m[1;49mINFO[0m bsra_3274952_19.0 odoo.modules.loading: loading l10n_us_reports/data/check_register.xml
> /home/odoo/src/odoo/18.0/addons/account/models/account_account.py(43)_check_account_type_unique_current_year_earning()
-> raise ValidationError(_('You cannot have more than one account with "Current Year Earnings" as type. (accounts: %s)', [a.code for a in account_unaffected_earnings]))
(Pdb) result
[(res.company(), account.account(94, 259, 347, 413, 481, 949, 1103))]
```
**customer database:**
```sql
bsra_3274952=> select id,name,active from res_company where id in (6,5,7,8,9,12,14);
id | name | active
----+-----------------------------+--------
8 | Credit Suisse _ AI 65-4 | f
14 | Indosuez- AI | f
6 | Credit Suisse _ AI 65-2 GBP | f
7 | Credit Suisse _ AI 65-2 USD | f
12 | Indosuez AI _ USD | f
9 | Indosuez AI _ GBP | f
5 | Vanity Living | f
(7 rows)
bsra_3274952=> select company_id, count(id) from account_account where account_type = 'equity_unaffected' group by company_id;
company_id | count
------------+-------
8 | 1
7 | 1
9 | 1
1 | 1
5 | 1
15 | 1
6 | 1
14 | 1
12 | 1
(9 rows)
```
- OPW: 5256021
- **Tested the solution on other db also:** [UPG-3273039](3273039)
- TBG: https://upgrade.odoo.com/odoo/upgrade.request/3274952/tbg/1309 (more dbs are failing)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr