Thursday, April 16, 2026
7 changes · saas-18.4
Resolved issues and error corrections
This update resolves a technical problem within the AI composer patch that was causing crashes. The fix ensures the focus event is correctly passed to the base handler, maintaining stability and preventing errors when the AI composer is used. This improves the overall reliability of the AI composer functionality.
Original PR description
**Purpose of this PR:** The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler. This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered. This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract. Related: odoo/odoo#258974 Task-5954657 Forward-Port-Of: odoo/enterprise#113763
This update ensures that transaction data pulled from iap uses the correct date range. Previously, incorrect date ranges could occur, leading to inaccurate reporting. This fix now uses the latest statement or statement line date, guaranteeing accurate data retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix corrects a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO company users.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves an issue where the checkout process became unresponsive when using Avatax with Brazilian tax identification. The previous code was unnecessarily calling external tax APIs, leading to errors that blocked the confirmation step. This fix removes the unnecessary API call, improving checkout stability and performance.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#113861 Forward-Port-Of: odoo/enterprise#112515
This update ensures that payments registered in the future are not processed according to Mexican tax regulations (CFDI). The system now filters out future payments, removing the 'Update Payments' button when only future payments are present, preventing incorrect tax signing and maintaining compliance.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#113945 Forward-Port-Of: odoo/enterprise#112320
This update fixes a potential issue where the year for payroll reports was defaulting to the current year, causing test failures. The change ensures the correct year is always referenced, preventing future errors and maintaining accurate reporting. This improves the reliability of payroll calculations.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325
This update resolves an issue where POS users with limited access rights were unable to fully close their Fiskaly VAT resolution sessions, requiring administrator privileges. The fix simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users handling Fiskaly transactions. This improves the reliability of the POS system for German customers using Fiskaly.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#112618