Monday, December 1, 2025
16 changes · saas-18.3
Enhancements to existing features
This update adds logging to the automated reconciliation process, making it easier to identify and resolve issues when it runs in user databases. Previously, debugging this process was difficult, and these new loggers will provide more visibility into the reconciliation's steps. This improves reliability and reduces potential disruptions.
Original PR description
For the moment, it's difficult to debug in users databases in the cron and the try auto reconcile. This commit will add some loggers to be more aware of what's going on. task-5358849
This update simplifies and streamlines testing of Odoo's accounting XML files. The new framework provides a standardized way to save, update, and manage assertions, reducing errors and making test maintenance easier. This improves the reliability of our 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 Forward-Port-Of: odoo/odoo#237435 Forward-Port-Of: odoo/odoo#237285
This update adds demo tax data and sample invoices to the Odoo Arabic localization (l10n_ar) module. This allows internal teams and reviewers to quickly test and verify that the correct tax calculations and reporting are displayed without needing to manually set up complex tax configurations. It simplifies the testing process for new legal requirements.
Original PR description
**Purpose of the PR** This PR introduces demo data to facilitate testing of the legal requirement implemented in v16 and forward-ported to all supported versions. **What it does** - Provides demo taxes (e.g., national, other categories). - Adds demo invoices combining different taxes. **Why** The demo data allows users and reviewers to quickly verify that the correct legal legend is displayed without having to manually configure taxes and create invoices. References: Adhoc task 53768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr CLA PR: https://github.com/odoo/odoo/pull/226715 Forward-Port-Of: odoo/odoo#226938
Resolved issues and error corrections
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and reduces potential errors.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#97417 Forward-Port-Of: odoo/enterprise#78380
A recent test failure related to editing event descriptions has been resolved. The fix clarifies the HTML tags used to ensure accurate modifications, drawing inspiration from a planned update in the next version. This improves the reliability of the event editing process.
Original PR description
The tour test testUI.test_website_event_tour was failling because the HTML tag specify to edit the event description was not precise enough and led to wrong modification. I specified the itemprop property of the specific tag to edit in order to erase the previous ambiguity. The proposed fix is inspired by the saas-18.4 version of the code. Runbot error: 226574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical error that prevented bookings from appearing correctly in the restaurant appointment system. The fix involves 'freezing time' to ensure bookings are always displayed accurately, regardless of date changes. This improves the reliability of appointment scheduling.
Original PR description
Depending on when the booking form was opened and closed you could end up no seeing the booking if the day had changed. Freezing time should ensure we don't have this scenario error-234349
This update resolves an issue where the system was incorrectly creating multiple bank accounts from UBL invoices. The fix filters out duplicate account numbers, ensuring accurate bank information is imported into Odoo. This improves data integrity and avoids potential accounting errors.
Original PR description
Currently `_import_retrieve_and_fill_partner_bank_details` may try to to create multiple res partner bank with the same account. This can i.e. happen in case there are multiple `cac:PaymenMeans` nodes in the XML. After this commit we filter out duplicate bank accounts numbers. opw-5149621 Forward-Port-Of: odoo/odoo#237850 Forward-Port-Of: odoo/odoo#236676
This update corrects a previous issue where the system incorrectly remembered the first invoice sending method chosen for a partner. This meant users wouldn't be able to easily switch to preferred sending methods like PEPPOL, leading to confusion. This change ensures users can now set their desired sending method without being automatically defaulted back to email.
Original PR description
Before this commit, we were setting the preferred invoice sending method on the Contact depending on what was in the first Send & Print to this specific partner. It's a bad idea because user don't know about this setting and when they want to switch the default method (example email -> peppol) the wizard will keep propose them to send it by email only and they don't know why since they never knowingly set it to "email". task-none (feedback from AVW) Forward-Port-Of: odoo/odoo#237956
This update resolves a recurring test failure (runbot-error-234594) related to timing delays in the Point of Sale module. The fix simplifies the test verification to ensure the `orderAcceptTime` field is present, improving the stability of the testing process.
Original PR description
in this commit: - Fixed the `_acceptOrder, _dispatchOrder, _completeOrder` test, which could fail due to minor timing delays. - Updated the assertion to only verify that `orderAcceptTime` is not empty. runbot-error-234594
This update fixes a technical issue where the Odoo system incorrectly handled failed RPC calls stored in its cache. Specifically, a cached promise would resolve with 'undefined' instead of properly rejecting the error, leading to unexpected behavior. This change ensures that RPC failures are correctly handled and reported, improving system stability.
Original PR description
Let's say we trigger two times a RPC that fails.
The first time, the cache is empty and we make the RPC. The ram cache is filled with `prom`.
The second time, we get `prom` from the ram cache.
When the RPC actually finishes, we end up in
```js
.catch((error) => {
this.ramCache.delete(table, key);
def.reject(error);
});
```
=> the RPC failure is catched, which means `prom` itself is not rejected. Instead, it resolves with the result of `.catch(...)`, which is `undefined`
Here is a simplified toy example:
```js
const prom = Promise.resolve(
Promise.reject(new Error("fetch failed")).catch(() => {})
);
```
In this example, `prom` is successful and the result is `undefined`
"
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-prA bug preventing test orders was fixed. The issue occurred when a product's tax was set as a 'Group of Taxes' without a defined tax rate. This update ensures that test orders can now be created successfully, even with this specific tax configuration, improving PoS functionality.
Original PR description
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module -…
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module - Configure Urban Piper integration for the PoS - Create a new tax without Definition > ``Tax Computation: Group of Taxes`` > Save - Create a new product > Set the above tax in sales taxes > Save - Open the session for PoS - Go to Settings > Urban Piper Location > Set Food Delivery Platforms > Save - Click Test Order > Select the product and Delivery Provider > Place Order Traceback: ```py IndexError: list index out of range ``` https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/pos_urban_piper/controllers/main.py#L319-L322 The issue happens because ``flatten_taxes_hierarchy()`` calls ``_flatten_taxes_and_sort_them()`` method at [1], which returns an empty record when the group tax has no children at [2]. As a result, ``tax_types`` becomes an empty list ([]), leading to an IndexError when trying to access ``tax_types[0]``. [1]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L2786 [2]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L795 sentry-6984648461 Forward-Port-Of: odoo/enterprise#98542
A rare bug in the system's request handling was causing errors during testing. This fix ensures the system correctly acquires a lock, preventing failures and improving the reliability of test results. This change addresses a technical issue that could impact the stability of the system.
Original PR description
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In…
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In this case, acquiring the lock is pointless since the late_request_thread has already finished, defeating the purpose of this quire, but we can workaround this keeping a reference to the main_lock before starting the thread. This way, even if the late_request_thread is already finished, we can still acquire the lock even if it is already released. Normal flow: - main_thread acquires main_lock - main_thread span request_thread - main_thread tries to acquire main_lock and again and blocks - request_thread runs and releases main_lock - main_thread acquires main_lock and continues When it fails - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock witch is None and fails Fixed - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock but it is already released - main_thread acquires main_lock and continues Runbot error [229827](https://runbot.odoo.com/odoo/runbot.build.error/229827)
This update resolves an issue where closing the article editing dialog would cause the page to jump back to the top. The fix ensures the correct element focus is maintained during dialog closure, improving the user experience and preventing unexpected page navigation.
Original PR description
Problem: When editing a long Knowledge article and executing the `/article` command, closing the dialog automatically scrolls the page to the top. Cause: This happens because `useActiveElement` inside the `Dialog` component runs its cleanup function when the dialog unmounts. While unmounting, `document.activeElement` is `body`, so the cleanup tries to focus back the `oldActiveElement`, which is the `editable`, and this resets the selection and causes the scroll jump. Solution: Set the selection when closing the dialog, ensuring the `editable` remains the `document.activeElement` during cleanup, preventing the focus reset. Steps to reproduce: - Edit a long article further down the page. - Use the `/article` command. - Dismiss the dialog. → The page scrolls back to the top. opw-4797567
This update fixes a technical issue that prevented the 'fuel_type' selection field in the HR contract model from being properly translated. By directly using the variable for options, this change ensures all available fuel types can be localized, improving the system's internationalization capabilities.
Original PR description
The selection field `fuel_type` in the `hr.contract` model was not properly translatable, because it used a function yielding static strings for the options. This commit changes the field to use the variable directly, allowing them to be translated. Forward-Port-Of: odoo/enterprise#100748
This update ensures that the available payment method options in the Point of Sale module are properly translated. Previously, these options were not handled for internationalization, leading to potential issues with localized versions of Odoo. This change improves the system's ability to support multiple languages.
Original PR description
The field `payment_method_type` got its selection values from a function that did not translate the labels. In order to make them translatable, we wrap them in a `env._()` call, so they are properly exported in the POT file and translated at runtime. Forward-Port-Of: odoo/odoo#237768
This update fixes an issue where short feedback messages were incorrectly wrapping the last word, creating a messy layout. The change ensures feedback messages display cleanly, especially when combined with the floating rating image, resulting in a better user experience. This was a minor visual improvement.
Original PR description
**Current behavior before PR:** - Short feedback wraps the last word unnecessary.  **Desired behavior after PR is merged:** - Short messages wrapped unnecessarily due to block-level element conflicting with floated rating image. This fix ensures cleaner inline layout.  Backport of this: [Commit](https://github.com/odoo/odoo/commit/52a1913ea7082655009c9eca1201c8c42e4e4037) task-[4788428](https://www.odoo.com/odoo/project/1519/tasks/4788428) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215577