Daily updates from Odoo
Friday, June 5, 2026
6 changes · 17.0
Resolved issues and error corrections
This update fixes a potential problem where users could accidentally trigger mass email campaigns bypassing campaign filters. The change prevents users from directly retrying failed mailings linked to marketing automation, reducing the risk of unintended spam and ensuring emails are delivered correctly through the campaign's intended targeting. A unit test has also been added for future maintenance.
Original PR description
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing…
When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam. This commit fixes the issue by: 1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`). 2. Hiding the "Retry" button in the frontend view to prevent confusion. 3. Adding a unit test to ensure this edge case is caught in the future. Steps to reproduce: 1. Create a marketing campaign with a filter and an email activity. 2. Run the activity and ensure at least one email trace fails. 3. Open the mailing template via the "Templates" smart button. 4. Click the "Retry" button on the template form. 5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model. OPW-6220106 Forward-Port-Of: odoo/enterprise#118759
This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports due to incorrect values in XML fields. Specifically, fields 2955 and 2956 must be set to zero, as dictated by eCDF regulations. Fixing this ensures reports are accepted by the eCDF system, preventing rejection and maintaining accurate financial reporting.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564
This update significantly speeds up the process of synchronizing participants with marketing campaigns. By optimizing a key function, the time taken to update campaign lists has been reduced dramatically – from over 51 seconds to just 0.65 seconds. This improvement will enhance the responsiveness of campaign management and improve user experience.
Original PR description
Replace search_read with search_fetch to avoid unnecessary _read_format call in backend context. Use OrderedSet instead of a custom _uniquify_list helper to get O(1) membership tests when computing records to add or remove from campaigns. Benchmark on a campaign with 115k participants: | Before PR | After PR | |:---------:|:--------:| | 51.71s | 0.652s | opw-6055334
This update fixes an issue where the Italian EDI bill import process only recognized the first tax listed in vendor XML files. Now, all taxes specified in the XML are correctly applied, ensuring accurate VAT calculations and reporting for Italian businesses. This improves data integrity and compliance.
Original PR description
Previously, the Italian EDI vendor bill import only processed a single tax per line. When the XML contained multiple tax entries, only the first one was considered and the remaining taxes were ignored. This fix updates the import logic to properly read and apply all taxes provided in the XML, ensuring the vendor bill accurately reflects the full tax structure defined in the file. task-5258180
This update resolves an issue where moving Odoo databases via the command line would inadvertently deregister subscription codes. The new `--move` flag ensures the database's original UUID is retained during a move, maintaining proper database registration. This improves the reliability of server-to-server database transfers.
Original PR description
### What & why `odoo db load` always calls `restore_db(..., copy=True)`, which forces the generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is the right default when…
### What & why `odoo db load` always calls `restore_db(..., copy=True)`, which forces the generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is the right default when *duplicating* a database, but it breaks the intended behaviour when *moving* a database between servers: Enterprise subscription codes are registered against the database UUID, so regenerating it deregisters the moved database. The web database manager already lets the user choose between copying and moving (the `copy` flag of the `/web/database/restore` route), but the CLI exposed no equivalent and forced a copy unconditionally. The CLI is the better tool for server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits and can run unattended or interactively. ### Steps to reproduce the current limitation 1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID) 2. On server B: `odoo db load mydb mydb.zip` 3. `database.uuid` has changed → the subscription is deregistered ### Fix Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`, keeping the original UUID. The default remains `copy=True`, so existing behaviour is unchanged. ```sh odoo db load mydb mydb.zip # unchanged: restore as a copy (new UUID) odoo db load --move mydb mydb.zip # new: restore as a move (keep the UUID) ``` ### Backport request This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well. Those are precisely the versions that ship the `odoo db` CLI subcommand, so the fix is applicable to all of them — which is why the backport range is 16.0 → 19.0 and stops at 16.0.
This update corrects a bug that prevented invoices for French public entities in DROM regions (like Martinique) from being correctly processed by Chorus Pro. The system was incorrectly substituting VAT numbers for SIRETs, causing routing failures. This ensures accurate invoice delivery and compliance.
Original PR description
When invoicing a French public entity through Chorus Pro, the SIRET of the recipient was written in the UBL PartyIdentification only when the partner country was France (country_code == 'FR'). Partners located in a DROM (overseas department/region) have a real French SIRET too, but their ISO country code failed the check, so the SIRET was dropped and replaced by the VAT number. This cause the invoice to not be routed correctly in Chorus Pro. Steps to reproduce: - Setup a french company and connect it to Peppol - Create a customer for a public entity located in Martinique, with its SIRET, Peppol address 0009:11000201100044 (Chorus Pro SIRET) and BIS Billing 3.0 format. - Issue and send an invoice to this customer via Peppol. - Open the generated *_ubl_bis3.xml: AccountingCustomerParty PartyIdentification/ID holds the VAT instead of the SIRET, and Chorus Pro never receives the invoice. opw-6153868