Saturday, August 1, 2026
7 changes · saas-19.4
Resolved issues and error corrections
Ecuadorian invoice printouts now include the company logo in the header again. The header layout was slightly adjusted so the logo fits properly within the existing printed invoice format.
Original PR description
### Issue: In 19.3, the EC invoice header completely replaces the standard header in `report_invoice_document` after commit `08d17cc49c` The company logo was not included in the custom header, leaving invoices without a logo ### Cause: The logo was simply missing from the header template ### Fix: The logo is added and some header elements are resized (`h5` → `h6`, reduced margin) to keep the layout within the existing paper format without requiring a new one ### Steps to reproduce: - Install `l10n_ec_edi` with demo data - Open and print any invoice Before the fix, the company logo is missing from the header opw-6377830 Forward-Port-Of: odoo/enterprise#125469
Audit reports now use the company selected for the report instead of defaulting to the user's main company. This prevents the wrong company address from appearing in accounting report headers when generating audit reports for another company.
Original PR description
When adding the accounting reports to the audit report, we browse the reports with the request's environment which is defaulting to the user's main company. As a result, the company's address displayed in the reports' header is not correct if we generate the audit report for any other company with a different address. https://github.com/odoo/enterprise/blob/aaab137897e6ad794247470e48d5ea91382577a3/account_reports/data/pdf_export_templates.xml#L85 We propose to inject the correct company in the report's environment. opw-6373956 Forward-Port-Of: odoo/enterprise#125125
The AutoComplete component wraps a text input that already renders its own suggestion dropdown, so the browser's native suggestions must stay out of the way. In 12/2024 in this commit [1] the input's autocomplete was switched from `off` to `new-password` on the premise that `off` is not respected by browsers. In 02/2025, in this commit [2] then made it the component default so many2x pickers stay clean. Chrome runs two independent suggestion mechanisms, and each attribute silences only
Original PR description
The AutoComplete component wraps a text input that already renders its own suggestion dropdown, so the browser's native suggestions must stay out of the way. In 12/2024 in this commit [1] the input's…
The AutoComplete component wraps a text input that already renders its own suggestion dropdown, so the browser's native suggestions must stay out of the way. In 12/2024 in this commit [1] the input's autocomplete was switched from `off` to `new-password` on the premise that `off` is not respected by browsers. In 02/2025, in this commit [2] then made it the component default so many2x pickers stay clean. Chrome runs two independent suggestion mechanisms, and each attribute silences only one of them: - `off` is ignored when the input has a name and Chrome holds autofill (address) data for it. - `new-password` is ignored when Chrome offers "frequently used values", i.e. the form-history dropdown. [3] So `new-password` does not always work. It only stays hidden while the field is ineligible for those suggestions. A field becomes eligible as soon as it gains an `id` and an associated `<label>`. On `saas-19.3` this is provable on commit [4] where adding a prefix icon gave the link popover URL input an `id` + `<label for>`, and the native dropdown resurfaced over the custom URL/page suggestions. This branch targets `saas-18.4`, where the regression is NOT reproducible because that URL input has no `id`/`label` yet. The fix is applied here anyway to avoid the gap that any later `label`/`id` addition re-exposes (as commit [4] proved), and the fix can be forward ported to `saas-19.3`. The website editor's URL field implements autocomplete without the `AutoComplete` component, so the default does not reach it. so `autocomplete="off"` is set directly on that input. [1]: https://github.com/odoo/odoo/commit/9c0f5612 [2]: https://github.com/odoo/odoo/commit/2980694b (opw-4551051) [3]: https://issues.chromium.org/issues/41163264#comment30 [4]: https://github.com/odoo/odoo/commit/2b4d04d1 (task-6034288) task-6370552 Forward-Port-Of: odoo/odoo#279560 Forward-Port-Of: odoo/odoo#277501
The discuss action's breadcrumb name is set asynchronously: a useEffect on the current thread's displayName calls setDisplayName after the OWL render. The tour clicked "Starred messages" then immediately clicked "View or join channels" (a sidebar category action that is always present, so there was no implicit wait). Under runbot load the starred render and its effect lagged, so the action was restored with the stale "Inbox" breadcrumb name and the ".breadcrumb-item:contains('Starred messages')"
Original PR description
The discuss action's breadcrumb name is set asynchronously: a useEffect on the current thread's displayName calls setDisplayName after the OWL render. The tour clicked "Starred messages" then immediately clicked "View or join channels" (a sidebar category action that is always present, so there was no implicit wait). Under runbot load the starred render and its effect lagged, so the action was restored with the stale "Inbox" breadcrumb name and the ".breadcrumb-item:contains('Starred messages')" step timed out.
This is a test-timing artifact: a real user always sees the starred view render before navigating away, so the breadcrumb is correct for them.
Wait for the starred thread to be displayed before opening the channels list, and assert the channels view opened via its "Public Channels" breadcrumb. Also use :text instead of :contains for the text selectors.
https://runbot.odoo.com/odoo/error/242893
Forward-Port-Of: odoo/odoo#279578
Forward-Port-Of: odoo/odoo#278909Steps to reproduce: - Enable the ZUGFeRD (or Factur-X) e-invoicing format on a German customer. - Create a sale order for that customer, confirm it, create an invoice with a down payment. - Confirm and send the invoice to generate the PDF/XML. - Validate the XML (e.g. on portinvoice.com): it is rejected because the invoice line is missing the mandatory ram:Name field, only ram:Description is present. Cause of the issue: a down payment invoice line created from a sale order no l
Original PR description
Steps to reproduce: - Enable the ZUGFeRD (or Factur-X) e-invoicing format on a German customer. - Create a sale order for that customer, confirm it, create an invoice with a down payment. - Confirm and send the invoice to generate the PDF/XML. - Validate the XML (e.g. on portinvoice.com): it is rejected because the invoice line is missing the mandatory ram:Name field, only ram:Description is present. Cause of the issue: a down payment invoice line created from a sale order no longer carries a product_id: it only has a free-text. The Factur-X/CII export template rendered ram:Name directly from line.product_id.name with no fallback. For a line without a product, this produced an empty ram:Name element, which cleanup_xml_node then stripped entirely from the XML, leaving only ram:Description. Solution: Fall back to the line's name when there is no product opw-6391121 Forward-Port-Of: odoo/odoo#277418
Issue: When clicking "Send & Print" on an Ecuadorian invoice and sending the email with both the PDF and XML attachments visible in the wizard, only the PDF attachment is sent Steps to reproduce: 1. Install l10n_ec_edi and enter EC Company 2. Create and post an invoice 3. Click "Send & Print" on the invoice 4. Notice that both the XML and PDF attachments show up on the wizard, but when clicking "Send", only the PDF attachment is attached to the email that gets sent out Cause: Before
Original PR description
Issue: When clicking "Send & Print" on an Ecuadorian invoice and sending the email with both the PDF and XML attachments visible in the wizard, only the PDF attachment is sent Steps to reproduce: 1.…
Issue: When clicking "Send & Print" on an Ecuadorian invoice and sending the email with both the PDF and XML attachments visible in the wizard, only the PDF attachment is sent Steps to reproduce: 1. Install l10n_ec_edi and enter EC Company 2. Create and post an invoice 3. Click "Send & Print" on the invoice 4. Notice that both the XML and PDF attachments show up on the wizard, but when clicking "Send", only the PDF attachment is attached to the email that gets sent out Cause: Before the "Send & Print" wizard opens, the XML is already created. When opening the "Send & Print" wizard, the XML is added to the wizard with a "skip: True" flag. This is used for the wizard dropdown to add already existing attachments on the invoice. When the attachment is not selected, it makes sense to not be sent. However, when the "Send & Print" wizard opens, the attachment is added by default and the attachments in the dropdown does not consider the attachments already attached to the wizard at the start. The duplicated attachment in the dropdown has the "skip: True" flag still so it will wrongly signal later on that the attachment should not need to be sent Solution: When loading invoice attachments into the wizard, skip any attachment that is already present in the wizard's attachment list, so that default send attachments are not accidentally duplicated with the skip flag opw-6351635 Forward-Port-Of: odoo/odoo#278985
When a PoS runs in a currency other than the company currency, product prices are loaded already converted to the PoS currency (`list_price`, `lst_price`, `standard_price` all go through `_convert_pos_data_currency`). The prices carried by combos were not: `product.combo.base_price` is computed in the combo currency (the company currency) and `product.combo.item.extra_price` is stored in the product currency, but neither was converted when loaded in the PoS. As a result, a product priced at 2
Original PR description
When a PoS runs in a currency other than the company currency, product prices are loaded already converted to the PoS currency (`list_price`, `lst_price`, `standard_price` all go through…
When a PoS runs in a currency other than the company currency, product prices are loaded already converted to the PoS currency (`list_price`, `lst_price`, `standard_price` all go through `_convert_pos_data_currency`). The prices carried by combos were not: `product.combo.base_price` is computed in the combo currency (the company currency) and `product.combo.item.extra_price` is stored in the product currency, but neither was converted when loaded in the PoS. As a result, a product priced at 2 USD (= 80 ZIG) was correctly shown as 80 ZIG on its own, yet appeared as 2 ZIG once it was part of a combo, since the raw amount was displayed as-is in the PoS currency. Convert `base_price` and `extra_price` from each record's own `currency_id` to the PoS currency at load time, mirroring what is already done for product prices. Steps to reproduce: - Set a product to 2 USD and a PoS to a ZIG pricelist (rate 40). - Open the PoS: the standalone product shows 80 ZIG. - Add the same product as a combo item: it shows 2 ZIG instead of 80 ZIG. opw-6410243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279253 Forward-Port-Of: odoo/odoo#278330