Daily updates from Odoo
Navigate
Branch
Saturday, November 15, 2025
42 changes
7 changes
Enhancements to existing features
Some India-specific accounting tags were missing their country assignment. This update adds the India country to those tags, which makes them easier to organize and reuse in other accounting scenarios.
Original PR description
Some account tags specific to India were missing the `country_id`. With this PR, the `country_id` is added to those tags, enabling easier group by and making them usable for other cases also. Forward-Port-Of: odoo/odoo#235538 Forward-Port-Of: odoo/odoo#235424
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
12 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
This update adds the India country link to several account tags that were previously missing it. It makes these tags easier to organize and reuse in other reporting or configuration scenarios.
Original PR description
Some account tags specific to India were missing the `country_id`. With this PR, the `country_id` is added to those tags, enabling easier group by and making them usable for other cases also. Forward-Port-Of: odoo/odoo#235538 Forward-Port-Of: odoo/odoo#235424
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 change removes an unnecessary database sequence created for point of sale sessions once the session is closed. It helps keep the database cleaner and avoids unnecessary buildup of database objects over time.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235815 Forward-Port-Of: odoo/odoo#235500
This 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
The VoIP contact search now skips the phone search field until at least three characters have been entered. This prevents an error from appearing as users type the first digits and makes the search experience smoother.
Original PR description
`phone_mobile_search` doesn't allow you to search for less than 3 characters. This commit excludes `phone_mobile_search` from the search domain when there are less than 3 characters. This avoids triggering an UserError on the first characters typed.
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
8 changes
Security fixes and vulnerability patches
This fix prevents employees from seeing appraisal goals that are not assigned to them, managed by them, or related to their reporting line. It protects sensitive performance information and ensures appraisal visibility matches the intended access rules.
Original PR description
Step to reproduce:
-------------------
1- Log as Mitchell Admin
2- Create a goal for an employee which is not one of Marc Demo
subordinnates and don't put him as goal's manager
3- Log As Marc Demo
You will see this goal.
You are not supposed to be able to see this goal.
Forward-Port-Of: odoo/enterprise#97121Resolved 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
This fix prevents the browser from reusing an outdated saved copy when a spreadsheet tab is duplicated. Users should now see the latest spreadsheet changes in duplicated tabs, reducing confusion and potential work errors.
Original PR description
It happens that browser may use a cache if there's no explicit cache control/expiration time: https://httpwg.org/specs/rfc9111.html#heuristic.freshness Steps to reproduce (non-deterministic): - create a new spreadsheet - do some changes, edit a few cells - right click on the tab and hit "Duplicate" => the spreadsheet is not up-to-date on the duplicated tab. The browser loaded the response from "disk cache" instead of fetching the latest data from the server. I'm using Chrom Version 142.0.7444.162 (Official Build) (64-bit) We add an explicit cache control. Forward-Port-Of: odoo/enterprise#99426
Fixed an error that could occur when adding a user to a new database project before any databases were linked. The user management wizard now handles this empty state correctly, preventing an unexpected crash and allowing the workflow to continue.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Go to Databases; 2. open a new project; 3. enter any name, hosting provider & URL; 4. under User Management, click on "Add a user". Issue ----- Traceback: > `ValueError: Compute method failed to assign databases.manage_users.wizard(<NewId 0x71e8c0d8fd80>,).everywhere_user_ids` Cause ----- The `_compute_everywhere_user_ids` method computes the value of a non-stored field. Consequently, every record in `self` needs have some value assigned to `everywhere_user_ids` during the compute, but currently, if the `database_ids` field is empty, `continue` is used without assigning a value. Solution -------- If the record doesn't have any known `database_ids`, set `everywhere_user_ids` to `None`. opw-5170587 Forward-Port-Of: odoo/enterprise#99200
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
The NACHA payment file now formats the company identification field according to official ACH rules. This helps payroll and payment files be accepted consistently by banks by using the correct spacing instead of zero-padding for this alphanumeric value.
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
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#9962812 changes
Enhancements to existing features
Some India-specific account tags were missing a country assignment. This update adds India to those tags so they are easier to organize and can be reused more reliably in other scenarios.
Original PR description
Some account tags specific to India were missing the `country_id`. With this PR, the `country_id` is added to those tags, enabling easier group by and making them usable for other cases also. Forward-Port-Of: odoo/odoo#235538 Forward-Port-Of: odoo/odoo#235424
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
Delivery slips now show separate lines for the same product when it is received in different packaging units. This makes the document more accurate and easier to read, avoiding confusion when products are delivered in multiple pack sizes.
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 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#234091Documentation and clarification updates
This change adds the contributor license agreement (CLA) signature for Raj Gohel. It is an internal legal/compliance update that allows contributions from this contributor to be accepted.
Original PR description
This pull request adds my Individual Contributor License Agreement (CLA) signature. Signed, Raj Gohel <rajgohel2018@gmail.com> https://github.com/Rajgohel0312
Miscellaneous changes
When merging the l10n cleanup for 19.0, I forgot to exclude the PO files already on Weblate. This commit fixes the merge conflicts caused by that.
Original PR description
When merging the l10n cleanup for 19.0, I forgot to exclude the PO files already on Weblate. This commit fixes the merge conflicts caused by that.
1 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