Friday, August 7, 2026
13 changes · saas-18.4
Enhancements to existing features
Receipt printer selection now follows the same broader matching rules already applied to preparation printers. This helps businesses connect compatible point-of-sale IoT printers more reliably without unnecessary filtering.
Original PR description
In odoo/enterprise#124306, we removed the subtype from the printer domain, but only for preparation printers. We also update it for receipt printers. Forward-Port-Of: odoo/enterprise#125648
Resolved issues and error corrections
This fixes an inconsistent automated test for selecting related records in the web interface. The change makes the test wait for the dropdown before choosing an option, helping reduce random test failures and keeping release validation more stable.
Original PR description
Before this commit, this test was sometimes failing. `edit("...")` validates the value by default (i.e. is followed by enter). It may happen that the dropdown is already open when doing so, and in this case, the first value is selected. However, it may often happen that it isn't open yet, so nothing happens.
To turn tests more robust, we typically turn off the auto confirm and call runAllTimers() to ensure the dropdown is open, then select the value. That's also what we did here.
runbot error-944120
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#280384Malaysian e-invoice exports now use the required fixed state code for customers outside Malaysia. This helps prevent MyInvois submission issues caused by sending non-Malaysian state names where a Malaysian state code is expected.
Original PR description
MyInvois expects the CountrySubentityCode to be fixed as '17' for customers located outside Malaysia, since Malaysian state codes don't apply to them. Set it to '17' instead of the raw state name for non-Malaysian customers. task-6388521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280855 Forward-Port-Of: odoo/odoo#280550
A packaging configuration error has been corrected so the IoT package build uses the right file path again. This restores the expected build process and prevents packaging failures caused by an outdated hardcoded path.
Original PR description
During the forward port of #278378, the dynamic NSI file path variable was overwritten by an old hardcoded one, breaking the IoT package build. Forward-Port-Of: odoo/odoo#280885
Opening Send & Print could fail for customers configured with a Belgian Peppol identifier but missing a Peppol endpoint. This fix prevents the error, allowing users to continue sending or printing invoices without interruption.
Original PR description
Currently, if you have a partner with Belgian VAT as peppol eas, but no peppol endpoint, you get a traceback when you open the Send&Print. It can happen easily, if you have customers without VAT or company registry, that were created 2 years ago, when we put Belgian VAT as default. 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#280344 Forward-Port-Of: odoo/odoo#280234
Employee list filters now ignore archived direct reports when identifying managers with direct subordinates. This prevents managers from appearing in results when they only have inactive employees under them, making HR searches more accurate.
Original PR description
Steps to reproduce: ------------------- 1. Install `hr` module 2. Create two employees (e.g., emp1 and emp2) and assign emp1 as the manager of emp2 → emp2 is now a direct subordinate of emp1 3. In…
Steps to reproduce: ------------------- 1. Install `hr` module 2. Create two employees (e.g., emp1 and emp2) and assign emp1 as the manager of emp2 → emp2 is now a direct subordinate of emp1 3. In the employee list view, apply the custom filter "Direct subordinates is set" (child_ids != False) → emp1 appears in the results as expected 4. Archive emp2 5. Apply the same filter again → emp1 still appears in the results even though it has no active subordinates Issue: ------ When an employee (e.g., `emp2`) is archived, their manager (`emp1`) should no longer appear in the "Direct subordinates is set" (child_ids != False) filter — since `emp1` no longer has any active subordinates. However, `emp1` still appears in the search results after `emp2` is archived, because the underlying EXISTS subquery checks all subordinates regardless of their active state. Cause: -------- Before this commit 5ef007a, `osv.expression`, filtering on a One2many field would automatically search against [active co-records ](https://github.com/odoo/odoo/blob/5f65e92d7fa341193df53f5aba1620b596f9a1ec/odoo/osv/expression.py#L1260-L1265)only by default. After that commit, the `condition_to_sql` method in `_RelationalMulti` constructs the comodel with [active_test=False](https://github.com/odoo/odoo/blob/463ca4cf867812890c17d1e1abf7640b04f70ad0/odoo/orm/fields_relational.py#L672-L686) when resolving relational field conditions. This causes the EXISTS subquery generated for `child_ids != False` to compare against all subordinates. (including archived ones rather than active ones only). Solution: --------- Added a callable `domain` attribute on the `child_ids` field definition so that only active subordinates are considered by default. This ensures [get_comodel_domain()](https://github.com/odoo/odoo/blob/2d8b24a791b6fe6bb214c32d4fb58b3d46eca70b/odoo/orm/fields_relational.py#L75-L85) returns a server-side domain that filters out archived subordinates, making the `child_ids != False` filter behave as expected. opw-6193104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266658
This fix prevents a test for invoice product prediction from failing when the optional Accounting Accountant module is not installed. It keeps automated checks reliable while still enabling product prediction coverage when the required module is available.
Original PR description
Description of the issue this commit addresses: The invoice product prediction test requires account_accountant but runs and fails when that optional module is not installed. --- Desired behavior after this commit is merged: This commit skips the test when account_accountant is not installed and enables product prediction when it is available. --- runbot-[941525](https://runbot.odoo.com/odoo/error/941525) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280874
Spreadsheet logging now excludes data sources that were loaded but found to be invalid. This prevents incorrect or noisy logging and helps keep spreadsheet usage data more reliable for analysis and troubleshooting.
Original PR description
The getter `getLoadedDataSources` was filtering out datasources that are not 'ready' but they should actually filter out datasources that were already loaded (so ready) but invalid. Task: 6387729 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#279153 Forward-Port-Of: odoo/odoo#276255
This update reduces rare false failures in an automated web test by increasing the timing buffer used during the check. It helps keep quality checks stable and prevents unnecessary investigation of random test failures, with no expected impact on users.
Original PR description
The test `waitForAnimationFrame does not trigger update if interaction is not ready yet` fails randomly (and seldom). The timeout and animation frame are treated together and appear at the same time in the verified steps. This is likely due to the timeout being too close to the animation frame and the task queue resolving them back to back. Giving a larger timeout (1s instead of 100ms) should solve the issue. runbot-939992 Forward-Port-Of: odoo/odoo#280708
This fix ensures Odoo refreshes its internal app list when modules are created or updated. Users can now activate newly discovered apps immediately after updating the apps list, avoiding repeated warnings and unnecessary server restarts.
Original PR description
Otherwise using the "Update Apps List" wizard (`base.action_view_base_module_update`) and then trying to `_get` the new module may not work because `_get_id` is `ormcache`ed. To reproduce: 1. Install `account_peppol` and `l10n_fr` 2. Delete the `l10n_fr_pdp` module from the apps 3. Go to the settings and click "Activate Electronic Invoicing" 4. Make sure "France FRCTC Electronic Address" is selected 5. Click on "Activate Peppol (Demo)" 6. Click on "Update App List" in the warning 7. Click on "Update" 8. Start over at step 3. and the same warning appears again, but the module can be found in the "Apps" already. Everything works fine after a server restart. task-None Forward-Port-Of: odoo/odoo#280938
Google Reserve availability responses now avoid reporting more open spots than total spots. This prevents confusing or invalid booking information when unusual appointment capacity settings are configured.
Original PR description
This commit makes sure that we never send more "spots_open" than there are "spots_total" when Google Reserve asks for availabilities. This could happen in very rare case when customers create configurations that do not make sense (for example a table of 6 but no management of capacities and configuring 125 spots per resource). Task-6449615 Forward-Port-Of: odoo/enterprise#126855
The Shop Floor view now preserves the intended ordering of work orders after refreshes or filter changes. This prevents confusing reordering when teams view work orders by work center, keeping priorities based on status and scheduled start date consistent.
Original PR description
Records already in cache are intended to be sorted by their position in `recordCacheIds` to preserve the previously computed display order. However, `recordCacheIds` stores database record ids (`resId`), and currently the cache lookup incorrectly uses `id` instead. As a result, every lookup returns `-1`, and could lead to inconsistent ordering. Steps to reproduce: 1. Create several manufacturing orders with work orders assigned to the same work center. 2. Give the work orders different states and scheduled start dates. 3. Open Shop Floor and display that work center. 4. Refresh the view or change a filter so the records are recomputed. It should use `resId` so the previously computed display order remains, which is based on state and scheduled start date. Related: odoo/enterprise#74421 opw-6402233 Forward-Port-Of: odoo/enterprise#125928
This update fixes an issue where a required Swiss payroll value was not being recorded during ELM transmission processing. It helps ensure payroll transmission records are complete and easier to audit or troubleshoot.
Original PR description
Forward-Port-Of: odoo/enterprise#127241