Friday, October 10, 2025
4 changes · 17.0
Enhancements to existing features
This update prepares Odoo IoT and POS IoT connections for upcoming Chrome local network access restrictions. It helps ensure local IoT devices remain reachable from Odoo in the browser, including when accessed through the odoo-iot domain, while also modernizing the connection code.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/231014 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This PR simply adds this change where appropriate. As part of this we have also backported the change from jquery -> fetch. task-5157145
This update helps Odoo Point of Sale continue connecting to local IoT devices, such as hardware connected through an IoT box, as Chrome introduces stricter local network access rules. It reduces the risk of disruption for businesses using POS hardware when browsers enforce the new permission behavior.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/96850 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This commit simply adds this change where appropriate. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Spanish Veri*Factu invoices now choose the correct regime key when export or exempt taxes are used. This prevents affected invoices from being marked as general regime operations when they should be classified as exports, improving compliance accuracy.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice for a partner outside Spain (or with the tax "0% EX G") - Check the "Veri*Factu Regime Key" under the page "Veri*Factu" - It should be "Export" (02) but it's "General Regime Operation" (01) ### Cause: `_l10n_es_edi_verifactu_get_suggested_clave_regimen()` is called on the tax "0% EX G". The line ```taxes.filtered(lambda tax: (tax.l10n_es_type not in main_tax_types or tax._l10n_es_edi_verifactu_get_applicability() != forced_tax_applicability))``` doesn't do what the comment says: remove the main taxes with a different applicability. ### Solution: Change the `!=` to `==` so that the line does the same thing as the comment. opw-5071665
GST return creation now looks for a valid purchase journal across all companies in a tax unit, instead of only the main company. This prevents setup-related failures when the main company lacks a purchase journal but another company in the tax unit has one configured.
Original PR description
Before this PR: - The system searched for a purchase journal only in `company_id`. - In a tax unit with multiple companies, if the main company had no purchase journal configured, record creation failed with a 'NOT NULL constraint violated' error. After this PR: - The journal search now checks all companies in `company_ids` (or falls back to `company_id`), - allowing the system to find a valid purchase journal across the tax unit. OPW: 5159518