Thursday, June 26, 2025
100 changes
8 changes
Miscellaneous changes
When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978
Original PR description
When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978
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#88580 Forward-Port-Of: odoo/enterprise#83963
In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The c
Original PR description
In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The currency code should go into Column C - The base currency amount (i.e. the company's local currency) should be shown in Columns E and F opw-4701001 Forward-Port-Of: odoo/enterprise#87786 Forward-Port-Of: odoo/enterprise#87002
- We authorize to make payments for orders coming from Urban Piper. - After updating the order as paid, we send it to the pos_blackbox_be. task-id: 4781945 community PR: https://github.com/odoo/odoo/pull/214861 Forward-Port-Of: odoo/enterprise#87989
Original PR description
- We authorize to make payments for orders coming from Urban Piper. - After updating the order as paid, we send it to the pos_blackbox_be. task-id: 4781945 community PR: https://github.com/odoo/odoo/pull/214861 Forward-Port-Of: odoo/enterprise#87989
In this commit: https://github.com/odoo/enterprise/commit/74306d39479f9cfb24bb749a520c533df3f7e404 change the computation of the remaining amount of the reconcile wizard. Since selectedLineSum compute the sum of the line selected when adding 2 lines the remaining amount would be changed and kept in the state. Then adding a line again, the selectedLineSum would be the sum of the 3 lines and not just the new line that we just added. no task id Forward-Port-Of: odoo/enterprise#88067
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/74306d39479f9cfb24bb749a520c533df3f7e404 change the computation of the remaining amount of the reconcile wizard. Since selectedLineSum compute the sum of the line selected when adding 2 lines the remaining amount would be changed and kept in the state. Then adding a line again, the selectedLineSum would be the sum of the 3 lines and not just the new line that we just added. no task id Forward-Port-Of: odoo/enterprise#88067
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
### Steps to reproduce: - Create 2 storable products: Product A, Product B - Create a control point pass/fail control by quantity on receipt and set both products on it. - Create and confirm a receipt with 2 moves: - 2 x Product A - 2 x Product B - Click on the "Quality Check" button and mark one unit of Product A as failed. > This should open the QC for product B. - Close the QC for prodcut B wihtout setting it as failed or passed. - Click on the "Quality Check" button ####
Original PR description
### Steps to reproduce: - Create 2 storable products: Product A, Product B - Create a control point pass/fail control by quantity on receipt and set both products on it. - Create and confirm a…
### Steps to reproduce:
- Create 2 storable products: Product A, Product B
- Create a control point pass/fail control by quantity on receipt and set both products on it.
- Create and confirm a receipt with 2 moves:
- 2 x Product A
- 2 x Product B
- Click on the "Quality Check" button and mark one unit of Product A as failed.
> This should open the QC for product B.
- Close the QC for prodcut B wihtout setting it as failed or passed.
- Click on the "Quality Check" button
#### > Nothing happends
### Expected behavior:
The QC for product B should open.
### Cause of the issue:
When the quality check is marked as failed, the related move is picked: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/quality.py#L438-L451 However, the move for your second porduct is not and hence, its product is not considered to be checkable by the `check_quality` action: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/stock_picking.py#L61-L69
Since these lines were added in c83728f3a7f1504b272f4ef97e4187868338adb3 to not bypass the QC of the unpicked move at validation we should probably only add that filtering condition in that case and continue to consider the unchecked moves as checkable prior to validation.
opw-4765075
Forward-Port-Of: odoo/enterprise#84743This commit automatically enables the 'Units of Measure' setting when the user auto-fixes their settings to make their POS scale certified. While this is not a strict requirement, it helps the users to then quickly set the correct units for their products (e.g. kg) task-4885681 Forward-Port-Of: odoo/enterprise#88451 Forward-Port-Of: odoo/enterprise#88134
Original PR description
This commit automatically enables the 'Units of Measure' setting when the user auto-fixes their settings to make their POS scale certified. While this is not a strict requirement, it helps the users to then quickly set the correct units for their products (e.g. kg) task-4885681 Forward-Port-Of: odoo/enterprise#88451 Forward-Port-Of: odoo/enterprise#88134
17 changes
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
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.
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
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