Thursday, June 25, 2026
9 changes · saas-19.1
Resolved issues and error corrections
The mailing theme selector now refreshes both the title and the preview when switching between favorite templates for different target models. This prevents users from seeing a mismatched preview and helps them choose the right mailing template more reliably.
Original PR description
Overview ------ When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first…
Overview ------ When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first show the template X with the correct title and preview, however when switching to model Y, the theme selector will show the title of the tempalte Y but the preview is always the one of template X. How to reproduce ------ 1. Create a new mailing for a target model X (e.g. `mailing.contact`) 2. Set a content for that mailing (you can choose from the existing themes) 3. Set that mailing as a favorite (using the favorite star button) 4. Create a new mailing for another target model Y. 5. Redo steps 2. and 3. 6. Create a new mailing, and set the target model to X (You should see the mailing X in the theme selector with the correct title and preview) 7. Change the target model to Y. Expected Behavior ------ Both the title and the preview of the mailing X in the theme selector should change into the title and the preivew of mailing Y. Current Behavior ------ The title of the template is changed into the one of Y however the preview remains the one of mailing X. Cause of The Issue ------ After the first mount of the `FavoritePreivew` component, when the template changes in the props, the body content of the preivew is not updated with the new value. Task-6332946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The page limit note in the website generator has been updated to use more general wording instead of a fixed number. This gives the system more flexibility to adjust page limits later without misleading users.
Original PR description
Page limit note fixed by being more general instead of stating a blatant 200. This gives us more leeway to control the nbr of pages IAP side.
This update extends an existing test safeguard so the accounting dashboard checks also block the newer Odoo Fin v2 endpoint. It helps keep automated tests fully isolated from live services, reducing the risk of unintended external requests during testing.
Original PR description
This commit follows up on [1] by extending the Odoo Fin request mock to cover the new version 2 (v2) favorite institutions endpoint. Previously, a mock was introduced to prevent the Clickall tool from making real external HTTP requests to `production.odoofin.com` when displaying the accounting dashboard. This update ensures that the newly introduced v2 URL is also safely intercepted, keeping the automated tests fully isolated from production servers. runbot-234936 [1] : https://github.com/odoo/odoo/commit/c6451015f1b01c3e1defe4a576989fd4bfdf2cdb Forward-Port-Of: odoo/odoo#271804
The Forecasted Demand edit button now stays visible even when the Forecasted Stock row is hidden in Master Production Schedule. This fixes a confusing display issue so users can still access forecast suggestions without changing unrelated row visibility.
Original PR description
Steps to reproduce:
1. Install Manufacturing.
2. Enable 'Master Production Schedule' in the Settings.
3. Go to [Manufacturing -> Planning -> Master Production Schedule].
4. Ensure 'Demand Forecast' and 'Forecasted Stock' rows are enabled from the dropdown.
5. Observe the edit pencil button next to 'Forecasted Demand' is visible.
6. Hide 'Forecasted Stock' using the rows filter dropdown.
Issue:
The edit pencil button ("Suggest Forecasted Demand") next to the 'Forecasted Demand' row disappears when the 'Forecasted Stock' row is hidden.
Expected behavior:
The edit pencil visibility should not be affected by the 'Forecasted Stock' row.
opw-6240596
Forward-Port-Of: odoo/enterprise#120208This change prevents the system from creating empty draft manufacturing orders for products that have no bill of materials. In these cases, replenishment rules will handle the request instead, which avoids unnecessary records and confusing production tasks.
Original PR description
Steps to reproduce: - unarchive the MTO route - Create a storable product "P1" with the MTO + Manufacture routes but set no Bill of Materials on it - Create a sales order with one unit of P1 and confirm it Problem: An empty draft MO is created even though no Bill of Materials exists. When no BoM is available, manufacturing orders should not be created, only replenishment rules are expected to handle this case. Fix: Added an early `continue` in `_run_manufacture` to skip MO creation when no BoM is found. opw-6174886 Forward-Port-Of: odoo/odoo#263108
This update resolves an issue where new modules could fail to install correctly when containing data for deleted records. The fix corrects a technical error within the `l10n_sa_edi` module, ensuring smoother and more reliable module installations. This prevents data loss and improves the overall stability of the system.
Original PR description
Installing a new module should be safe even when the module contains new data for records that have been deleted. It is not the responsibility of the localization to make sure of that. The fix in `l10n_sa_edi` had 2 issues: * calling `self.env.ref` instead of `self.ref` * Checking for the existence of records even in the case of installing the CoA for the first time on a company, which obviously doesn't contain anything. This results in always ignoring the data.
This update resolves an issue where the CoA reload process unintentionally modified existing financial reports. The CoA framework is now responsible for managing these records, ensuring data integrity and preventing unexpected changes. This change improves the stability and reliability of financial reporting within the system.
Original PR description
It is the burden of the CoA framework to check for that. See community commit for more information.
This update resolves a technical error preventing the Spanish E-Invoice module (`l10n_es_edi_verifactu`) from functioning correctly during upgrades. The fix ensures the necessary 'certificate' module is loaded first, preventing a system error that blocked the module's operation. This ensures a smoother upgrade process and reliable functionality for users.
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#271827 Forward-Port-Of: odoo/odoo#271496
This update fixes an issue where quality alerts weren't being created when receiving emails without a company assigned. The fix ensures that a default company is now automatically applied, preventing errors and guaranteeing that all incoming emails are properly recorded within the quality alert system. This improves data accuracy and reporting.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#118516 Forward-Port-Of: odoo/enterprise#109947