Daily updates from Odoo
Wednesday, February 18, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue preventing payroll users from accessing the 'One-time payments' feature within Swiss company contracts. The fix allows authorized payroll users to manage these payments, ensuring accurate payroll processing. The problem stemmed from restricted access to internal action records, which has now been addressed through a secure internal bypass.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll Officer/Manager access. 4.…
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll Officer/Manager access. 4. Log in as that user, create a contract, and click on "One-time payments". Issue: --------- A Traceback with AccessError: ```You are not allowed to access 'Action Window' (ir.actions.act_window) records.``` Cause: ---------- https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195 The code attempts to call `.read()` on an `ir.actions.act_window` record. Standard users typically do not have read access to window action records, resulting in an **AccessError** even if they have rights to the payroll data. Solution: ------------- Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction. opw-5491467 Forward-Port-Of: odoo/enterprise#106598
This update resolves a bug where autofilling pivot cells with incorrect relational IDs caused a crash. The fix ensures that the autofill process itself functions correctly, while preventing the associated tooltip from triggering a system failure. This improves the reliability of pivot table data entry.
Original PR description
If you try to autofill a pivot cell that has an invalid relational id in its domain (eg. `=PIVOT.HEADER(1, "stage_id", 99999999)`), the autofill actually works but the tooltip make everything crash. Task: [5913754](https://www.odoo.com/web#id=5913754&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#107502 Forward-Port-Of: odoo/enterprise#106601
This update resolves an issue where archived employees were still visible in the attendance Gantt chart. The change ensures that only currently active employees are displayed, improving data accuracy and clarity for reporting. This prevents confusion and ensures users only see relevant attendance records.
Original PR description
Steps to reproduce: 1. install `hr_attendance_gantt` 2. create an employee 3. make attendance records for the employee in the previous months 4. archive the employee When opening the gantt view of the attendance, a row appears for the archived employee, with no attendance showing up. This commit adds a constraint to only show the active employees. opw-5490119 Forward-Port-Of: odoo/enterprise#106486
This update corrects a bug where the 'CFDI to Public' checkbox was incorrectly checked when creating new invoices in the Mexican accounting module. The fix ensures this checkbox remains unchecked until a customer is selected, preventing incorrect public invoice generation. This improves data accuracy and compliance for Mexican businesses using Odoo.
Original PR description
Steps to produce: --- - Install `l10n_mx` and `accountant` modules. - Switch to a Mexican company. - Go to Accounting > Customers > Invoices. - Click on New to create a new invoice. Issue: --- - The `CFDI to Public` checkbox is automatically checked even when no customer is selected. Root cause: --- - Here at [1], the field l10n_mx_edi_partner_address_complete evaluates to False when no partner is set. - Due to the OR condition, this causes l10n_mx_edi_cfdi_to_public to be set to True, even though no partner has been selected yet. Solution: --- - We should only evaluate partner address completeness when a partner is explicitly set. - Also, add VAT check for `l10n_mx_edi_partner_address_complete`, as requested by mial(PO). [1] https://github.com/odoo/enterprise/blob/cc00e8f3bb75b8c782fea3a42ad3bbcdbc240e2f/l10n_mx_edi/models/account_move.py#L649 opw-5911542 --- Forward-Port-Of: odoo/enterprise#106943
This update fixes an issue where CFDI refund XMLs were using a generic description instead of the original line details. Now, refund descriptions accurately reflect the returned items, ensuring proper compliance with Mexican tax regulations. This change aligns with a previous update in version 19.0.
Original PR description
Steps to produce: --- - Install `accountant` and `l10n_mx` modules. - Switch to Mexican company. - In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`. -…
Steps to produce: --- - Install `accountant` and `l10n_mx` modules. - Switch to Mexican company. - In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`. - Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice. - Mark the invoice as global. - Register the payment. - Create a credit note and confirm it. - Click Send(make sure CFDI is checked) and check the generated XML. Issue: --- - The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`. Solution: --- - Preserve the original line description for CFDI refunds instead of forcing the generic label. - For POS refunds, continue using the generic label. - This aligns with the fix introduced in 19.0([here]). Before: --- <img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" /> After: --- <img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" /> [here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436 **Backport of https://github.com/odoo/enterprise/pull/97681** opw-5870052 --- Forward-Port-Of: odoo/enterprise#107739 Forward-Port-Of: odoo/enterprise#107367
This update ensures payslips display the employee's actual start date with the company, rather than the contract start date. This is crucial for accurate payroll reporting, especially when employees transition between roles internally. The change applies to both Switzerland and the UAE due to localized payslip reports.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598
This update reverses a recent change that was causing all upsell quotes to be canceled, disrupting legitimate business processes. The previous update incorrectly used a function that resulted in errors and prevented proper filtering of alternative quotes. This reversion restores the correct functionality.
Original PR description
…mmit/55b6bbe27cc31abcaee40cd4a196e087fdfd4ce5 This commit introduced an issue. All upsell quote were canceled and no filtering was done on "alternative quotes". As a result it could disrupt legit business flow. Moreover, action_cancel was called instead of _action_cancell which can lead to ValueError: Expected singleton as action_cancel can require single record sometimes. Forward-Port-Of: odoo/enterprise#107503 Forward-Port-Of: odoo/enterprise#107417
This update addresses a recent discovery that the SAT (Mexican tax authority) sometimes accepts accented characters in invoices. Previously, the system automatically removed accents to comply with SAT rules. This change temporarily allows the ‘É’ character, and further investigation is underway to determine the optimal approach for full SAT compliance.
Original PR description
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT…
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely. The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`. Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515) Forward-Port-Of: odoo/enterprise#107677