Daily updates from Odoo
Saturday, June 27, 2026
4 changes · 18.0
Resolved issues and error corrections
This change fixes the XML produced for Danish eInvoices when a line has both a tax and a discount. The invoice file now includes the missing tax classification details, so it passes Nemhandel validation and can be sent without errors.
Original PR description
### Steps to Reproduce 1. Activate l10n_dk 2. Have a Danish customer contact where the eInvoice format is OIOUBL 2.1 3. Create an invoice with them as the partner and make sure that the line has a…
### Steps to Reproduce 1. Activate l10n_dk 2. Have a Danish customer contact where the eInvoice format is OIOUBL 2.1 3. Create an invoice with them as the partner and make sure that the line has a tax and a discount 4. Download the XML and try to validate ### Description of the issue/feature this PR addresses: **Issue:** When sending customer invoices with discounts on lines with the OIOUBL 2.1 format, the generated XML fails official Nemhandel validation. The schematron rejects the file because line-level allowance blocks do not declare their tax classifications. Specifically, this violates mandatory compliance rule [F-LIB226], which says that one `TaxCategory` class must be present inside every `cac:AllowanceCharge` block on a line item. **Solution:** By using the target dictionary array after the base framework is generated, it gets the line's tax information using native grouping functions. It then injects the `cac:TaxCategory` sub-block directly into each array item mapping. ### Current behavior before PR: When a product line includes a discount, Odoo outputs a standard line-level `cac:AllowanceCharge` block. It does not include the necessary tax information. This incomplete XML causes Nemhandel to throw an error. ### Desired behavior after PR is merged: Every line-level discount allowance generated for a Danish invoice will include the relevant tax classification metadata downstream into the XML. This will ensure that it is accepted by Nemhandel. opw-6226549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that key records created when using Marketing Automation templates, such as the confirmed contacts list and its related action, are kept during system upgrades. As a result, users will no longer see these template-generated items disappear after upgrading the module.
Original PR description
When a user chooses the "Double Opt-in" template (or others using `_create_records_with_xml_ids`), the system creates records like the "Confirmed contacts" list and a server action. It also adds an…
When a user chooses the "Double Opt-in" template (or others using `_create_records_with_xml_ids`), the system creates records like the "Confirmed contacts" list and a server action. It also adds an `ir.model.data` entry for them under the module, but sets `noupdate=False`. The problem is that during a module upgrade, Odoo's cleanup process (`_process_end`) deletes any record marked `noupdate=False` if it wasn't "reloaded" from a file. Since these records are created manually in the code and aren't in any XML file, they never get reloaded, so Odoo just deletes them and the records they point to. By setting `noupdate=True` when these rows are created, we tell the system to leave them alone during upgrades. Since these only exist at runtime and don't have a data file, we don't need to worry about them being updated later anyway. The helper was added in https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833. Steps to reproduce: 1. Install Marketing Automation 2. Go to Campaigns > New and pick the "Double Opt-in" template, then save 3. Confirm the "Confirmed contacts" mailing list and server action exist 4. Go to Apps and Upgrade Marketing Automation 5. Try to find the mailing list and server action again => They disappear after the upgrade. Ticket [link](https://www.odoo.com/odoo/project.task/6140191) opw-6140191
When users scan a product in the Barcode app, the system now better preserves the product owner on the delivery line when this information is available. This helps ensure existing stock is used correctly, avoiding unnecessary creation of new stock entries and reducing inventory inconsistencies.
Original PR description
### Steps to reproduce: - In the settings enable: "Storage Locations" and "Consignment" - Create a storable product and put 1 unit in stock with a set owner - Go to the barcode app > Operations >…
### Steps to reproduce: - In the settings enable: "Storage Locations" and "Consignment" - Create a storable product and put 1 unit in stock with a set owner - Go to the barcode app > Operations > Delivery Orders > New - Scan your product and validate #### > The owner was not set on the stock move line so that a new quant was created and updated in stock rather than using the available unit. ### Cause of the issue: The mechanism of prefilling an owner or a package in the barcode app is currently gate-kept behind the existence of a lot name: https://github.com/odoo/enterprise/blob/0be4f71de3420fb9b72fd4e70d48c6cbbbc0ecb4/stock_barcode/static/src/models/barcode_model.js#L1382-L1407 However, the option also make sense for none tracked products. ### Note: Performing the flow form the backend and adding quantity will generate the move line by setting the owner if possible since the quantity of a move is set via the back end, move lines are generated by looking at the existing quant data's: https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2364 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2328-L2330 Setting the same owner on the new move line as on the quant we are going to reserve: https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L2337 https://github.com/odoo/odoo/blob/5d61c03b33c9a915684dd59656f8be7612956dd1/addons/stock/models/stock_move.py#L1715 Additional subtelties appearing when prefilling for non tracked product: 1. Currently the available quantity is not taken into account to determine if the the value provided to the prefilled is actually relevant, in particular if there is a quant with an available quantity of 0, it will be used as a valid value to prefill and it will parasit the prefill that could be done by other quants. 2. The location source used to determine the quants taken into account is not set on the first scan since the scan is performed without any existing line: https://github.com/odoo/enterprise/blob/4f0d25f9fe4ca8ff1b0ecd7900899a2a246ba888/stock_barcode/static/src/models/barcode_model.js#L1387 > This was not problematic with respect to tracked product since the product needs to be scanned prior to the lot, hence there is always a current line when the the lot is scanned. opw-6050657
This update fixes the website cookie bar layout so its buttons and links keep the right spacing when a layout is selected. It also prevents popup elements from being inserted inside other popups, avoiding confusing editing behavior on the website.
Original PR description
Steps to reproduce: - Enable the cookies bar in the website settings. - Go to the website and enter edit mode. - Open the cookies bar from the invisible elements panel. - Open the snippet dialog. => Popup snippets are still visible even though they cannot be dropped inside another popup. Before this commit, popup snippets could still use dropzones located inside another popup in some cases, such as cookie bars or newsletter popups. After this commit, when the dragged snippet is a popup, dropzones inside an existing popup are filtered out, so nested popups cannot be inserted. task-6251151