Tuesday, November 25, 2025
15 changes · 18.0
Enhancements to existing features
This update streamlines accounting test creation by introducing a standardized helper for asserting and saving XML files. This simplifies test maintenance, reduces errors, and provides a more organized approach to XML handling within the Odoo accounting tests.
Original PR description
> This is a backport of the merged https://github.com/odoo/odoo/pull/235565 - with a couple of improvements & adaptations to the test files. This commit adds helpers and improves on the way we assert…
> This is a backport of the merged https://github.com/odoo/odoo/pull/235565 - with a couple of improvements & adaptations to the test files. This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an XML tree/string to an XML file should call the `assert_xml` helper, and design their test file name/location/etc. around this framework. This approach has a few major benefits: Assert / Save XML When testing XML files, we often need to perform create/read/update operations on the asserted XML to make sure it corresponds to the most updated/intended data. Previously, to save something to an XML, a developer would need to write their own local helpers to save the XML in the right directory. This was cumbersome and error-prone, so we decided to design a helper that allows developer to immediately save AND/OR update the asserted XML: to save/update an XML, we can simply add `SAVE_XML` as an additional test tags. Better test naming and optional subfolder management To better organize test files, the `assert_xml` method allows us to write just the test key name (without `.xml`), and the framework will automatically get the XML to assert/save from the `test_files` directory. An optional `subfolder` parameter is also added to allow writing to specific subfolder within `test_files`. Better `___ignore___` management in assertion XMLs Sometimes, we want to ignore a few XML node that are not relevant, or have content that are not deterministic (changes on every test run). To handle this, previously, developers would need to modify the assertion XML content by hand or write their own local script to do so. With this new framework, we just need to add an `ignore_schema.xml` file somewhere in the `test_files` directory. If put inside a subfolder, it will be applied with more priority towards the XML that are put on that specific subfolder. Save "pure" XML (before applying `___ignore___`) in temporary folder When calling `SAVE_XML`, before applying the ignore patches, the XML will be saved in a temporary folder (same folder as the screenshots for tours), so that developers can use them in external tests in the future, and for any other saving reasons. In addition, this commit also: - add `extra_tags` helper to save all the common tags for EDIs, for a better way to enable `EXTERNAL_MODE` testing inspired by `l10n_mx_edi` - convert some non-assert XML test helpers into a class method - canonicalize the XML to ensure consistency of the generated test files following the C14N Version 2 standard. (Deterministic namespaces location, sorted attributes, etc.) task-4891206
Resolved issues and error corrections
This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix corrects a typo in the XML data, ensuring customers now use the correct receivable account for reporting purposes. This ensures accurate SAFT report generation and compliance.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009 Forward-Port-Of: odoo/enterprise#99196
This update corrects a technical issue where stopping ringtone playback caused unintended HTTP requests to '/null'. The fix resets the element's source, eliminating this problematic behavior and improving performance. This ensures the application functions smoothly without unnecessary network activity.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update corrects a visual issue in the Contacts module where the 'parent_id' field in the new contact form lacked a placeholder. The fix ensures that the placeholder 'Company Name...' is displayed correctly when creating a new individual contact, improving the user experience.
Original PR description
### Steps to reproduce: - Go to Contacts > Contacts > New - Change it to "individual" type #### > The "parent_id" field should have a place holder "Company Name..." ### Cause of the issue: The…
### Steps to reproduce: - Go to Contacts > Contacts > New - Change it to "individual" type #### > The "parent_id" field should have a place holder "Company Name..." ### Cause of the issue: The `parent_id` field of the res.partner form uses the `res_partner_many2one` widget: https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/odoo/addons/base/views/res_partner_views.xml#L164-L166 and is therefore relying on the `PartnerAutoCompleteMany2XField`. However, this template tries to recover its placeholder from the `placeholder` attribute of the Component: https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/partner_autocomplete/static/src/xml/partner_autocomplete.xml#L41-L50 even thought this attribute is not defined and the placeholder should be recovered from its props: https://github.com/odoo/odoo/blob/60e0529b98098b019ade09aad97cc6e359bc0755/addons/web/static/src/views/fields/relational_utils.xml#L35-L38 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing the successful installation of the UK Construction Industry Scheme for companies with branches. The previous version created duplicate account codes, resulting in installation errors. Now, the system correctly handles branch companies, allowing for seamless UK reporting installation.
Original PR description
Before this commit: Steps 1) Create a UK localization company 2) Create a branch for that company 3) Try to install UK - Construction Industry Scheme (l10n_uk_reports_cis) => A Validation Error is raised with the message `Account codes must be unique. You can't create accounts with these duplicate codes: 220001, 220101, 220201`, This occurs because the `_l10n_uk_reports_cis_post_init()` method is creating accounts for each UK company even if they aren't root companies (branch). After this commit: UK - Construction Industry Scheme (l10n_uk_reports_cis) is installed successfully with UK companies that have branches. opw-5326079
This update streamlines account reporting settings for users in specific countries. It automatically displays relevant settings based on report type (monthly, non-monthly) and fiscal year, preventing confusion and ensuring accurate reporting. This improves the user experience by only showing necessary options.
Original PR description
We're adding several countries to the settings, each time a user from this country has specific fiscal year and does non-monthly reporting. It's cumbersome, as we have to know in which country it's acceptable. At the same time, we don't want to show a setting if it's useless to the user. It will just confuse him. So, we should show this setting as soon as the report will complain: - If it's monthly and he does not start at the beginning of the month. - If he does non-monthly and does not end on 31st of December. We could be even more selective and also compute which months would be valid if in quarterly and other modes but we think it's fine for these cases.
This update fixes an issue where archived users were incorrectly sending out automated follow-up emails for invoices and partners. The change ensures that only active users are designated as the sender, preventing misdirected notifications and improving email reliability. This resolves a bug identified in version 18.0.
Original PR description
### Issue: If an archived user is set as the Sales person on an invoice or as the followup responsible on a partner, it will be the one sending the automatic followups. ### Steps to reproduce: - Create a partner and an overdue invoice for this partner - Change the "Salesperson" of the invoice to another user - Archive this user - Accounting > Customer > Followup Reports - Click on the partner created earlier - Click the actions and "Process Automatic Follow-ups" - [17.0] Traceback - [18.0+] The sent message is from the user that was archived ### Cause: `_get_followup_responsible()` does not check is the users it returns are active or not. ### Solution: Create an iterable with all the possibilities and iterate on it to return the first active user in the list. Fallback on `self.env.user`. opw-5153159 Forward-Port-Of: odoo/enterprise#98807
This update resolves an issue where subsequent patches weren't consistently applied within the Odoo web module. Specifically, if the object itself isn't utilized, subsequent patching attempts fail. This change ensures that patches are correctly applied, addressing a technical limitation that could impact future updates. The fix was prompted by a related issue and is part of the ongoing maintenance of the Odoo web module.
Original PR description
If we don't use the object itself, we can't get subsequent patches. One example where this is needed: https://github.com/OCA/web/pull/3365 cc @moduon MT-11823 fyi @yajo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that caused payments using the 'Own Checks' method in foreign currencies to fail due to an incorrect calculation. The fix corrects a typo in the code, ensuring payments are properly balanced and processed correctly. This improves the reliability of outgoing payments.
Original PR description
Setup: - Install l10n_latam_check - Set an outstanding payment account on the outgoing payment method "Own Checks" in the "Bank" journal. - Activate a foreign currency Steps to reproduce: - Go to "Accounting/Vendors/Payments" - Create new payment with a foreign currency, with the journal "Bank" and "Own Checks" as payment method - Create 3 "Checks" lines (whatever dates or amounts) - Post -> Invalid Operation: The entry is not balanced. Issue: - There appears to be a typo in `_l10n_latam_check_split_move`, where `liquidity_balance` is used instead of `liquidity_balance_total` opw-5151228
This update enhances the compatibility of the Enterprise module with newer IoT Boxes (v19.1 and above). The change ensures proper functionality by verifying the 'bb status' within the system's data tracking, resolving a previous issue related to formatting inconsistencies. This update maintains a smooth experience for users utilizing IoT Box integrations.
Original PR description
We now check the bb status in `data.status` in addition to `data.status.status` to ensure compatibility with v19.1+ IoT Boxes. This commit also fixes an issue introduced in [this fw port](https://github.com/odoo/enterprise/pull/100205), where 2 lines where mistakenly unindented
This update fixes an issue where the Activity Menu's filtering options (Late, Today, Future) didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these options work consistently and align with other Odoo modules. This improves the user experience for managing approvals.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#99632
This update resolves a problem where the exchange rate was missing from invoices generated with certain currencies in Odoo 18. The underlying issue stemmed from how multiple country templates were linked, causing conflicts. This fix focuses on correcting the display of the exchange rate for invoices, ensuring accurate reporting.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company -> in 17.0, the exchange rate is missing -> in 18.0, the template is broken The same fix can be applied for both 17.0 and 18.0. The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236844
This update resolves an issue where the account no followup feature wasn't consistently working correctly. The fix involves optimizing the search process for better accuracy and reliability, ensuring data is processed properly before searching. This improves the overall functionality of the account no followup module.
Original PR description
- unwrap Markup before applying regex substitution - word-bound search term
This update resolves an issue where document previews were not updating correctly after renaming documents. Previously, the preview displayed the old attachment name even after a successful rename. This change ensures that document previews always reflect the most current document name, improving data consistency and user experience.
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433This update fixes a translation error in the Netherlands (l10n_nl) module. The description for the 9% ST tax was previously incorrectly translated as 'TVA' (VAT). This change ensures accurate reporting and compliance with Dutch tax regulations, improving the accuracy of financial data.
Original PR description
The traduction of te description of the 9% ST tax was wrong and was TVA to get back on a sale tax task-5217323 Forward-Port-Of: odoo/odoo#236655