Thursday, June 26, 2025
27 changes · 18.0
Enhancements to existing features
This update clarifies how Odoo's record creation method can be used, allowing tools to recognize both single-record and multi-record inputs. It helps developers get better editor guidance without changing business workflows or user-facing behavior.
Original PR description
As soon as the `model_create_multi` decorator exists, `create()` function arguments can be either a list of dict values or a single dict. Moreover, make IDE's happy when creating with single dictionary values. @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting report test cases were updated to use the default outstanding payment and receipt accounts that are now created automatically with the chart of accounts. This reduces test conflicts and helps keep accounting report validation aligned with current setup behavior.
Original PR description
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: - Use the correct default account codes directly (101403, 101404) - Avoid reassignment of codes that are now created by the CoA template task-4826385
Resolved issues and error corrections
This fix prevents invoice line units of measure from being changed unnecessarily when related Kenya localization logic is triggered. It helps avoid incorrect invoice details and keeps accounting calculations, such as quantities and discounts, consistent.
Original PR description
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute…
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute function](https://github.com/odoo/enterprise/blob/18.0/l10n_ke_edi_oscu_stock/models/account_move.py#L166) to the `product_id` field on invoice lines. The ORM triggers computes for all items in the chain - irrespective of whether the value was changed or not. Therefore, when the Kenya modules are installed, the `_compute_product_uom_id` function is triggered - which changes the unit of measure. Solution: Improve the account.move.line's `_compute_product_uom_id` to only change the UoM when necessary. Considered Alternatives: - Whilst the l10n_ke_edi compute functions are not ideal - it was done because there was no PO/Bill matching feature at the time. Ideally these computes should be removed - but that would impact the stable policy and may have knock on effects. - changing the tests would simply hide issues arising from uom's and discounts. runbot-75230
Miscellaneous changes
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single
Original PR description
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single record uses `message_post` which calls `_message_set_main_attachment_id`. While in the case of a batch, it is not. Solution -------- Explicitly link `mail.message` attachments to the original `account.payment` record. Similar to what is done for `account.move` attachments that are linked to the `account.move.send` records. OPW-4500389 Forward-Port-Of: odoo/odoo#202906 Forward-Port-Of: odoo/odoo#202345
This fix prevents an unnecessary error from appearing when a direct call connection is closed while the system is switching to a fallback connection method. It improves call reliability by avoiding misleading tracebacks, with no expected change to normal user behavior.
Original PR description
Before this commit, there could be a race condition where the peer connection gets closed while an offer is being negotiated. This could happen for example when offers are being sent to establish a p2p connection and the fallback to the SFU kicks in and clears the connection. This would lead to a traceback but no functional issue.
This fixes an unreliable bus monitoring test that could fail when the browser reported no network connection. The connection status is now handled consistently regardless of whether the issue comes from the network, client, or server, helping keep automated validation stable.
Original PR description
This commit fixes the non-deterministic `connection considered as lost after failed reconnect attempt` test. The monitoring service does not show the connection as lost when the navigator online property is false which makes this test fail when network is not available. This check makes no sense, it doesn't matter if we lost the connection because of a server/client error or because the network is down. This commit removes this check on the "online" navigator property and fixes this test. fixes runbot-226892 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
Customers using self-ordering are now sent back to the product page if their cart is empty instead of being allowed to continue to payment. This prevents checkout errors and creates a smoother ordering experience.
Original PR description
Before this commit: ================ Users could attempt to proceed with payment even when the cart had no orderlines After this commit: =============== If the cart is empty, the user is automatically redirected back to the product page, preventing the error and ensuring a smoother user experience. Task-4880984
Fixes an issue where deleting a signature could leave behind an invisible signature area that caused newly typed content to be placed in the wrong container. This makes editing emails or documents with signatures behave more predictably after users clear signature content.
Original PR description
### Steps to Reproduce: - Insert a signature (e.g., using /signature). - Press Ctrl + A, then press Backspace — signature content is removed. - Press Backspace again — o-signature-container div remains. - Any new content is inserted inside the empty o-signature-container. ### Description of the issue/feature this PR addresses: - Empty signature containers were not converted to base containers on backspace. ### Desired behavior after PR is merged: - A predicate was added that checks for empty blocks of types: pre, heading, blockquote, and signature. This ensures empty signature containers are also converted to base containers on backspace. task-4793734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The analytic distribution table now remains usable on mobile devices when many columns are present. Users can horizontally scroll the table instead of having content hidden, making expense and accounting workflows easier on small screens.
Original PR description
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added…
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added style="max-width: 100vw;" to table-responsive wrapper to enable horizontal scrolling on smaller screens. Steps to Reproduce: 1. Install the Expenses and Accounting modules. 2. Go to Settings → Search for Analytic Accounting → Enable it. 3. Add multiple analytic plans with sufficient data to cause horizontal overflow. 4. Navigate to Expenses → Open any record. 5. Open Inspect in your browser → Switch to mobile view. 6. Click on Analytic Distribution. <details><summary>Images</summary> <p> before FIX:  after FIX:  </p> </details> Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4805590) opw-4805590
Removing a linked image in the HTML editor now properly closes the link popover and cleans up the empty link. This prevents a confusing leftover popup and keeps edited content cleaner.
Original PR description
Before this commit: 1. Insert an image and add a link to it. 2. Click on the image and remove it by clicking the remove button in the toolbar. 3. The link popover remains open and only disappears after clicking away. This occurs because the default behavior of a link with text preserves the link element to allow the possibility of completely changing the label of the link directly in the editing area. After this commit: The link popover is properly closed when an image link is removed, and the link element is removed when the link element associated with the image is empty. task-4805029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Colombian electronic mandate module now clearly requires the Colombian DIAN module it depends on. This prevents installation, upgrade, or uninstall errors when companies use Colombian electronic invoicing features.
Original PR description
The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined…
The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined in `l10n_co_dian` module, and the workflow in the module also depends[[1]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_invoice.py#L9)[[2]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/product_template.py#L8) on DIAN being installed. Both modules have the same dependency `l10n_co_edi` and are autoinstalled. This can easily break if the user chooses to uninstall the dian module. The module will fail to install if dian is not installed. The uninstall of the dian module will also cause an error if this module is installed. The upgrade will fail if the user has dian uninstalled (edi_mandate is a new module and will try to autoinstall) This fix makes the dependency explicit.
The Philippine BIR 2307 XLS export checks now reflect the required ZIP code field and use the correct tax description for the nature of payment. This helps ensure withholding tax reports match regulatory expectations and reduces the risk of incorrect export validation.
Original PR description
The BIR 2307 XLS export was missing the `ZIP_code` and incorrectly showing the `nature` of payment from the invoice line instead of the tax description. In this commit: --- - updates the tests to include the `zip_code` column and fetch the correct `nature` from the tax description. - adjust name fields to reflect `individual` vs `company` partner logic. task-4880921 community- odoo/odoo#214940
Fixed an issue that could cause translated referral sharing links to fail. This helps employees share referral links more reliably across languages.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198
When building `base_tax_line_mapping`, the JOIN on `affecting_base_tax_ids` was effectively scanning the CTE as many times as there were tax lines in the domain. This lead to computing a number of rows equivalent to the number of base lines times the number of tax lines; so O(n²). Using a LATERAL JOIN helps in avoiding that behavior and only getting the lines needed in each loop.Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#215411
Original PR description
When building `base_tax_line_mapping`, the JOIN on `affecting_base_tax_ids` was effectively scanning the CTE as many times as there were tax lines in the domain. This lead to computing a number of rows equivalent to the number of base lines times the number of tax lines; so O(n²). Using a LATERAL JOIN helps in avoiding that behavior and only getting the lines needed in each loop.Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#215411
Moved quantity update logic into `handleOrderLineQuantityChange`for better readability, reuse and overrides. task-id: 4771749 enterprise PR: https://github.com/odoo/enterprise/pull/85137 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209282
Original PR description
Moved quantity update logic into `handleOrderLineQuantityChange`for better readability, reuse and overrides. task-id: 4771749 enterprise PR: https://github.com/odoo/enterprise/pull/85137 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209282
@moduon MT-10568 MT-10569 MT-10567 MT-10566 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#214739
Original PR description
@moduon MT-10568 MT-10569 MT-10567 MT-10566 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#214739
It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere. As this file was changed in 18.0 another PR was needed : https://github.com/odoo/od
Original PR description
It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere. As this file was changed in 18.0 another PR was needed : https://github.com/odoo/odoo/pull/209625 task-4650439 Forward-Port-Of: odoo/odoo#209623
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number. Current behavior before PR: Duplicated sequence numbers are generated Desired behavior after PR is merged: Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number
Original PR description
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and…
Description of the issue/feature this PR addresses:
if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number.
Current behavior before PR:
Duplicated sequence numbers are generated
Desired behavior after PR is merged:
Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number duplication
Script I used to reproduce the issue:
```python
import threading
import xmlrpc.client
url = 'http://localhost:8069'
db = 'db_name'
username = 'admin'
password = 'admin'
common = xmlrpc.client.ServerProxy('{}/xmlrpc/2/common'.format(url))
uid = common.authenticate(db, username, password, {})
models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(url))
models.execute_kw(db, uid, password, 'ir.sequence', 'unlink', [models.execute_kw(db, uid, password, 'ir.sequence', 'search', [[('code', '=', 'test.sequence')]])])
models.execute_kw(db, uid, password, 'ir.sequence', 'create', [{
'name': 'Test Sequence',
'code': 'test.sequence',
'prefix': 'TEST-',
'suffix': '/%(month)s/%(range_year)s/10001',
'padding': 1,
'number_increment': 1,
'use_date_range': True,
}])
def get_sequence_number():
return models.execute_kw(db, uid, password, 'ir.sequence', 'next_by_code', ['test.sequence'])
for i in range(5):
threading.Thread(target=get_sequence_number).start()
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210277For Jordan E-invoicing, the reason for return of a credit note is mandatory in the XML. Before this commit, if the return reason (`ref`) was empty in a credit note, an error from JoFotara pops up during validation. This commit makes sure the user is notified of missing `ref` before submitting the XML to JoFotara. task-4869028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215542
Original PR description
For Jordan E-invoicing, the reason for return of a credit note is mandatory in the XML. Before this commit, if the return reason (`ref`) was empty in a credit note, an error from JoFotara pops up during validation. This commit makes sure the user is notified of missing `ref` before submitting the XML to JoFotara. task-4869028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215542
Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation. Forward-Port-Of: odoo/enterprise#88563 Forward-Port-Of: o
Original PR description
Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation. Forward-Port-Of: odoo/enterprise#88563 Forward-Port-Of: odoo/enterprise#88341
Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²). Forward-Port-Of: odoo/enterprise#88261
Original PR description
Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²). Forward-Port-Of: odoo/enterprise#88261
Users can now add a negative quantity product (e.g. cautions) without needing to locate the original order to refund it. We make sure that negative order contains only negative lines and prevents mixing with positive quantities to avoid confusion. task-id: 4771749 community PR: https://github.com/odoo/odoo/pull/209282 Forward-Port-Of: odoo/enterprise#85137
Original PR description
Users can now add a negative quantity product (e.g. cautions) without needing to locate the original order to refund it. We make sure that negative order contains only negative lines and prevents mixing with positive quantities to avoid confusion. task-id: 4771749 community PR: https://github.com/odoo/odoo/pull/209282 Forward-Port-Of: odoo/enterprise#85137
When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88493
Original PR description
When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88493
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#86118
Original PR description
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#86118
When the fields from the models account.move.line and account.analytic.line have the same name but a different type, a traceback is raised when an analytic filter is set on a report. opw-4769750 Forward-Port-Of: odoo/enterprise#87374 Forward-Port-Of: odoo/enterprise#85599
Original PR description
When the fields from the models account.move.line and account.analytic.line have the same name but a different type, a traceback is raised when an analytic filter is set on a report. opw-4769750 Forward-Port-Of: odoo/enterprise#87374 Forward-Port-Of: odoo/enterprise#85599
This commit will change the condition of display of the coda_split_transactions allowing users to choose whether transactions are imported individually or in batch. opw-4873108 Forward-Port-Of: odoo/enterprise#88370
Original PR description
This commit will change the condition of display of the coda_split_transactions allowing users to choose whether transactions are imported individually or in batch. opw-4873108 Forward-Port-Of: odoo/enterprise#88370
This commit solves the following bugs in Norwegian saft as per customer feedback: 1. Removed the StandardAccountID 2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty. This case may happen if, for example, we have an exchange rate entry = $0.000001. Since the journal entry is approximating to only 2 decimal places,
Original PR description
This commit solves the following bugs in Norwegian saft as per customer feedback: 1. Removed the StandardAccountID 2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty. This case may happen if, for example, we have an exchange rate entry = $0.000001. Since the journal entry is approximating to only 2 decimal places, the amounts on the entry end up being 0s. task-4714764 Forward-Port-Of: odoo/enterprise#88523 Forward-Port-Of: odoo/enterprise#83963