Wednesday, June 24, 2026
12 changes · saas-18.4
Enhancements to existing features
This update makes the e-invoicing report template easier to adapt without conflicts from other customizations. It reduces the chance of report-related issues when other modules or third-party changes adjust the same invoice layout.
Original PR description
**Description of the issue/feature this PR addresses:** As the new `xpath` is expecting a very specific type of `t-if` which is possibly changed in other templates of third parties or even Odoo itself which do not depend on this module, we take a more robust approach to identify the block **Current behavior before PR:** Issues with inherited views outside the dependency tree (because of primary=True) **Desired behavior after PR is merged:** Less friction and smoother identifier of the needed diff Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270605
Resolved issues and error corrections
The HTML editor now prevents command menus and automatic markdown formatting from activating while users are typing in code blocks. This avoids errors and keeps code content from being unexpectedly converted into tables or lists.
Original PR description
### Steps to reproduce: - Go to ToDo. - Create a code block using `/code`. - Place the cursor inside the code block. - Type `/table` and select the table command. - A traceback occurs. ### Purpose of this PR: - Commands and markdown shorthands should not be available inside code blocks. However, typing `/` inside a `<pre>` opened the command palette, allowing structural commands such as `/table` to be executed and causing a traceback. Similarly, markdown shorthands such as `* ` and `1.` were still active, unexpectedly transforming code content into lists. ### This PR fixes the issue by: - Disabling the command palette when the cursor is inside a `<pre>` element. - Disabling markdown shorthands inside `<pre>` elements by registering an `is_shorthand_available_predicates` predicate. task-6292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271101 Forward-Port-Of: odoo/odoo#269430
This update adjusts an internal mail-related test so it works correctly with PostgreSQL 18, which reports a database constraint error differently than earlier versions. It helps keep automated quality checks reliable without changing customer-facing behavior.
Original PR description
This commit is kind of a follow up of
odoo/odoo@39cd4ea856fe00f5674f8c44b2b66cbf2705426d (in 18.0).
In a nutshell, following a standard-compliance fix (postgres/postgres@086c84b) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_alias_domain_setup`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "mail_alias_domain" violates RESTRICT setting of foreign key constraint "mail_alias_alias_domain_id_fkey" on table "mail_alias"
DETAIL: Key (id)=(191) is referenced from table "mail_alias".
This commit updates the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes.
Forward-Port-Of: odoo/odoo#271403
Forward-Port-Of: odoo/odoo#271302The Mozambique demo company now uses a valid NUIT tax identification number. This prevents validation errors in newer dependency versions and helps automated checks and demo data load correctly.
Original PR description
Newer versions of stdnum (2.2) also test the number for MZ We did not have a valid NUIT number in the MZ demo company. Runbot error: https://runbot.odoo.com/runbot/build/114118067 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#271398 Forward-Port-Of: odoo/odoo#271299
Receipts now ignore cancelled stock moves when calculating their deadline. This prevents outdated dates from cancelled purchase order lines from keeping a receipt deadline stuck at the wrong value, improving schedule accuracy for warehouse and purchasing teams.
Original PR description
Steps to reproduce the bug:
- Create a Purchase Order with 2 products and confirm it
- Note the receipt's deadline (= date_planned of both lines)
- Set the quantity of one PO line to 0
- Update the scheduled date (date_planned) of the purchase order
Problem:
the receipt deadline does not update.
The receipt kept the old deadline from the cancelled move. When a PO line qty is set to 0, `_merge_moves` cancels the corresponding stock move via `_action_cancel`. Then `_update_move_date_deadline` correctly skips cancelled moves (filtered by `state not in ('done', 'cancel')`), so the cancelled move retains its original `date_deadline`. However, `_compute_date_deadline` on `stock.picking` used
`move_ids.filtered('date_deadline')`, which not checks move state, so the stale deadline of the cancelled move was included in the min/max computation.
opw-6292600
Forward-Port-Of: odoo/odoo#270985This update improves internal spreadsheet testing by allowing tests to check behavior before list data has finished loading. It helps ensure spreadsheet list features handle loading states correctly, reducing the risk of regressions for users.
Original PR description
Added the parameter `skipWaitForDataLoaded` to `createSpreadsheetWithList` to test what happens when the list is not ready yet. Task: [6289944](https://www.odoo.com/odoo/2328/tasks/6289944) 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#271144 Forward-Port-Of: odoo/odoo#269096
The Mauritania country flag image has been updated to the correct version. This ensures users see accurate country identification wherever flags are shown in Odoo.
Original PR description
[task-6320443](https://www.odoo.com/odoo/project.task/6320443) Forward-Port-Of: odoo/odoo#271488
This fix ensures Odoo's gevent server loads database registries during startup so important registry settings are applied consistently. It helps prevent configuration issues that could affect server stability in deployments using this server mode.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271640
The Spain VeriFactu module now explicitly loads its required certificate component before use. This prevents installation or upgrade failures in cases where the certificate feature was not already loaded.
Original PR description
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to…
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises: ``` TypeError: Model 'certificate.certificate' does not exist in registry. ``` ### Cause `models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`. ### Notes - Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op. - Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first. Forward-Port-Of: odoo/odoo#271496
This fix restores the intended behavior that hides the column count option for specific website building blocks. It prevents users from seeing or changing an option that should be unavailable, keeping the website editor experience consistent after a recent refactoring.
Original PR description
The class 's_nb_column_fixed' was used to hide the column count option, but it got lost during the refactoring and doesn't work since 18.4. This commit restores it. task-6234267
This update prevents an error that occurred when the 'Company Car (To order)' option was enabled in the salary configurator. The fix ensures that a car model is selected before attempting to extract data, resolving a technical issue that previously blocked users from configuring this option. This ensures the salary configurator functions correctly for all users.
Original PR description
## Steps to Reproduce: (v18.0) 1. Install `l10n_be_hr_contract_salary` without demo data. 2. Create a Belgian company and switch to it. 3. Create an employee. 4. Create a contract for the employee. 5. Click Generate Offer and open the Salary Configurator. 6. Enable the 'Company Car (To order)' option. ## Error: `AttributeError: 'NoneType' object has no attribute 'split'` ## Cause: When the salary configurator is used without demo data, no car model is selected. The method assumes that select_wishlist_car_total_depreciated_cost always contains a value and directly calls split() on it, resulting in an error, when the field is None. ## Fix: This commit checks that both the company car option is enabled and a car model has been selected before trying to extract the model ID. sentry-7554712017 Forward-Port-Of: odoo/enterprise#121138
This update fixes an issue where the spreadsheet edition's autofill tooltips would display error messages instead of the correct data when the list was not yet loaded. The fix ensures tooltips display the intended information reliably, improving the user experience. This was part of a larger effort to enhance stability and usability.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#121228 Forward-Port-Of: odoo/enterprise#119876