Tuesday, January 20, 2026
20 changes · 18.0
Enhancements to existing features
This update organizes UBL test files for better compatibility with future move formats and improved schema validation. The test files have been moved to a more structured folder within the account_edi_ubl_cii module, streamlining testing and development efforts. This change supports ongoing improvements to the UBL invoice generation process.
Original PR description
This commit rearranges the UBL test files' subfolder to be one level higher, from `export/bis3/be` to `export/bis3/invoice/be`, in preparation for supporting different move formats and for better ignore schema support. task-4891206
Resolved issues and error corrections
This update resolves an issue where product names on invoices were being incorrectly concatenated due to newline characters. The fix replaces newlines with spaces, ensuring names and descriptions remain readable and adhere to API specifications, preventing data processing errors. This improves invoice accuracy and compliance.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120
Code cleanup and technical improvements
This update streamlines testing of Odoo's accounting XML invoices (GT and MX) by introducing a standardized helper function for asserting and saving XML files. This simplifies test maintenance, reduces errors, and allows for more flexible test data management, improving overall test reliability.
Original PR description
> This is a backport of the merged https://github.com/odoo/enterprise/pull/99434 - with a couple of improvements & adaptations to the test files. This commit adds helpers and improves on the way we…
> This is a backport of the merged https://github.com/odoo/enterprise/pull/99434 - 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 - refactor `l10n_mx_edi*` modules to use these helpers related-community-PR: https://github.com/odoo/odoo/pull/237258 task-4891206
This update corrects a previous error that prevented the installation of the `l10n_mx_hr_payroll` module. The demo company's name has been restored and updated to align with other accounting modules, ensuring proper functionality and installation.
Original PR description
This is a fix of commit 6bf73fe9e7fdba62411bee188a28f7ad4c489093 that mistakenly removed the demo company's name in `l10n_mx_hr_payroll`. As a result, the installation of `l10n_mx_hr_payroll` fails (unless `l10n_mx` is installed, in which case the demo company already exists). We need to reinstate the demo company's name, while changing it to `ESCUELA KEMPER URGATE` for consistency with the accounting modules. runbot-237826
This update fixes a technical issue that caused errors when Odoo servers were shut down. Specifically, a problem with how server stops handled database connections resulted in errors. This change ensures a smoother and more reliable server shutdown process, preventing disruptions.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 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#244481
A test was failing due to a sale order not requiring payment. This update forces the sale order to always require payment, ensuring the test now passes. This resolves a technical issue that could have impacted the reliability of the website sale functionality.
Original PR description
version: 17.0+e Why ? --------------- test_payment_provider_visibility_with_portal didn't pass on runbot because the sale order used doesn't reqire payment. The fix --------------- Force the sale order to require a payment. runbot-237786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244322
This update clarifies to users with neutralized Peppol instances that the system is currently operating in demo mode, rather than production. Previously, the settings were unclear, leading to potential confusion. This change improves user understanding and ensures accurate system configuration.
Original PR description
In settings, it is not clear for users with neutralized instances that peppol is no longer in production, and that it is in demo mode task-5149768 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
This update corrects a bug where canceled duplicate emails were not automatically deleted from the system, leading to unnecessary storage. The fix ensures that duplicate emails are handled correctly during the sending process, preventing archive buildup and improving email management efficiency. This resolves an issue reported in opw-5247192.
Original PR description
**Steps to reproduce:** - Go to Contact app - Create two contacts with the same mail - Add a common tag to each of them - Go to Email Marketing app - Create new mailing - Ensure `keep_archives` is disabled in campaign settings - Select Contact as Recipient Model - Create a custom rule on tag to mach both contacts - Send the mailing out - Email will be present in the chatter of the second contact **Issue:** The `auto_delete` setting of the mail is only applied on `outgoing` mails. As duplicate mail `state` and `failure_type` are set with: ```py mail_values['state'] = 'cancel' mail_values['failure_type'] = 'mail_dup' ``` They are ignored by the `_send` loop and won't go though `_postprocess_sent_message` which delete the rest. **Fix:** Delete such mails on sending like it is done in the postprocess. opw-5247192
This update prevents errors when creating inter-company invoices by ensuring payment terms are compatible with the receiving company. Previously, invoices automatically used the payment term of the originating company, leading to posting failures. Now, the system correctly applies only company-specific payment terms.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both…
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies. * Create a **payment term** assigned to **Company A**. * Create a **sale order** from Company A to Company B using that payment term. * Confirm the sale order and create the **invoice**. * Post the invoice to trigger the inter-company vendor bill. **Observed behavior:** * The generated **vendor bill** for Company B uses **Company A’s payment term**. * Posting fails because the payment term is incompatible with Company B. **Cause:** * Inter-company document creation reuses payment terms without checking whether they belong to the **target company**. * Payment terms from the source company can be propagated to the destination document. **Fix:** * Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices. * Payment terms belonging to a different company are now ignored. **NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution. opw-5392745 Forward-Port-Of: odoo/enterprise#102986
This update resolves an issue where registration emails for events were displaying duplicate headers and footers due to an incorrect email layout being applied. The fix removed a redundant setting, ensuring consistent and professional email communications for event attendees. This improves the overall user experience.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767
This update fixes an issue preventing users from booking appointments that ended at 23:00-00:00. The system was incorrectly interpreting the end of the day as an unavailable slot. The change ensures that these slots are now correctly recognized and available for booking, improving appointment scheduling functionality.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892
This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for major shipping carriers (UPS, FedEx, USPS, DHL). By mapping these modules, the connector now functions properly with these carriers, ensuring accurate order processing and shipping information. This improves the reliability of the Amazon integration.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings. Forward-Port-Of: odoo/enterprise#102606
This update corrects a technical error in the l10n_au_hr_payroll module that was causing a warning message to appear incorrectly on the TFN dashboard. The fix ensures accurate reporting of TFN status for employees, preventing potential payroll issues. This update was triggered by a specific configuration related to employee TFN status.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_au_hr_payroll. 2. Enable multi-company and switch to an AU company. 3. Change an existing employee’s company to the AU company ([employee…
Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.
Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.
Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.
**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.
opw-5459998This update removes a previously implemented fix for the website slides module, streamlining the code and preventing duplication. The change ensures the fix remains contained within the portal_rating module, improving efficiency and reducing potential maintenance overhead. This update is crucial for maintaining a clean and reliable user experience.
Original PR description
Following the changes in PR #236475, the fix in PR #232696 is no longer required. This commit reverts commit 4c02c970ed824e2b1ade90b905365519044abc69, ensuring that the fix remains within the portal_rating module and preventing duplicate code for the same issue. This change should be forward ported up to saas-18.2. For later versions, the revert is already handled in PR #243783.
This update resolves an issue where users would receive an error when selecting a company after it had been unarchived. The problem stemmed from a timing conflict in how the system refreshed company data. This change ensures that the system correctly identifies and allows access to recently unarchived companies, improving usability.
Original PR description
**Steps to reproduce** - Have at least two active companies - Archive one company - Unarchive the company - Select the just unarchived company in the company selector - `Access Error: Access to unauthorized or invalid companies.` **Cause** There was a timing issue between the cache invalidation and the call to super. After the cache invalidation, if `_get_company_ids` of `res.users` was called before the call to `super` in the `write`, it would not return the just unarchived company. opw-5449925 Forward-Port-Of: odoo/odoo#244482
This update resolves an error that prevented non-employee users from creating expenses from documents. The issue stemmed from a required field ('employee_id') being unintentionally set to 'false' when no employee was linked to the user. The fix now displays a user-friendly error message instead of crashing the system.
Original PR description
Currently an exception is generated when the non-employee user tries
to generate expenses from the documents.
Steps to produce an error:
- Install the `documents_hr_expense` module without demo data
- Delete employee `Administrator`
- Upload any PDF/image file inside the company's `Internal` folder
- Click on the uploaded document and click on the `Create an Expense` button
Error: `ValueError: NotNullViolation('null value in column "employee_id" of ...`
This error occurs because `employee_id` is required when creating an
expense. Since the current user is not linked to an employee record,
`employee_id is` set to false, which causes the issue.
This commit resolves the issue by raising a `UserError` when the current
user is not linked to an employee.
sentry-7192984733This update resolves an issue where accessing settings in the Romanian language version of Odoo resulted in an error. The fix corrects a mismatch in text references within the Odoo codebase, ensuring the settings app functions correctly when the Romanian language is selected. This improves usability for Romanian-speaking users.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346
This update resolves an issue where FedEx labels incorrectly displayed addresses containing special characters (like accents or non-English characters). The change ensures all addresses are converted to ASCII characters, resulting in accurate and consistent label formatting for FedEx shipments. This prevents misinterpretations and ensures proper label printing.
Original PR description
Issue ----- Fedex does not handle special characters in addresses, so passing an address such as "Rue de Libération 15" will show as "Rue de Lib...ration 15" on labels. ----- Ticket: opw-5419724
This update resolves an issue where the 'Month 13' column in the Mexican l10n_mx Trial Balance report incorrectly displayed numbers. The fix removed a redundant 'balance' column, ensuring accurate reporting of financial data. This improves the reliability of financial reports for Mexican businesses using Odoo Enterprise.
Original PR description
With l10n_mx company: 1 - Add the balance column to the “Trial Balance” accounting report 2 - Create a journal entry for the date 12/31/2024 for 5000 as a credit on the account 119.01.01 VAT due and balance it with 5000 as a debit on another account 3 - Open the Trial Balance report and click on the “Month 13” filter as well as the year 2024. Notice that the “Month 13” column has some numbers when there should not be a number in that column. Delete the balance column from the “Trial Balance” accounting report and notice that the numbers now appear in their appropriate columns. In the _l10n_mx_set_options_month_13 the way to find the initial value, month 13 and end value columns was hardcoded. opw-5222117 Forward-Port-Of: odoo/enterprise#104105
This update fixes a potential issue with the Odoo file upload service. Previously, the service struggled to handle different response types from Odoo controllers (JSON, JSONRPC, or HTML), leading to errors. Now, the service is more robust and handles a wider range of error responses, ensuring smoother file uploads.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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