Monday, January 26, 2026
8 changes · 18.0
Enhancements to existing features
This update simplifies how businesses can customize event registration pages. By separating the registration logic, developers can now easily inherit and modify the underlying system using the 'prepare' method, leading to more flexible and tailored event experiences. This change enhances the extensibility of the website event module.
Original PR description
Since this controller returns raw markup, it is impossible to inherit. By splitting the controller `registration_new`, allows to manage custom developments with the inheritance of the prepare method instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves a problem that occurred during Odoo 18 upgrades when using the l10n_id module. The migration script was incorrectly creating extra tax records, leading to errors. This fix ensures a smoother and more reliable upgrade process for Odoo users with the l10n_id module installed.
Original PR description
Encountered an issue during upgrade from v16 with existing l10n_id installed on the DB. The script will try to force create the tax and create extra `repartition_line_ids` which is causing multiple "base" line to be added and trigger the `ValidationError`. Upgrade request: [3442445](https://upgrade.odoo.com/odoo/request/3442445) Upgrade task: [5314508]( https://www.odoo.com/odoo/70/tasks/5314508) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237897
This update resolves an issue where General Ledger exports were incomplete for some customers due to a NULL value in the 'include_initial_balance' field. The fix ensures that all accounts are included in the batch XLSX export, preventing data omissions. This improves the reliability of financial reporting.
Original PR description
…LSX export We recently added a batch export for the xlsx file for the General Ledger as the basic export was having a memory error. To handle it, we first determine which accounts are present in the report by running a custom query which uses the computed boolean field include_initial_balance. It appears with some customers' tickets that this field is set to NULL in their databases. This value might potentially come from a legacy artifact from an older Odoo version. I have not found a way to reproduce the issue without running a custom query. For customers having this field set to Null, it results in an incomplete export where these accounts are missing. opw-5787298 opw-5797979 Forward-Port-Of: odoo/enterprise#105275
This update corrects a validation error occurring when processing vendor bills through ARCA in Argentina. The change ensures the required 'CodAutorizacion' field is correctly included in the data sent for verification, resolving issues where the system couldn't find this crucial information. This prevents delays and errors in the bill validation process.
Original PR description
In this commit https://github.com/odoo/enterprise/pull/103370/changes#diff-2459e118c605cf039bb94c62561285ad753b6a27c571f10a25547ee9b01aa318R289 where a refactor has been made, the field 'CodAutorizacion' was left as 'invCodAutorizacion' on _l10n_ar_edi_get_request_data_verify. This leads to errors when validating vendor bills on ARCA, since the organism could not find the required field. <img width="640" height="163" alt="image" src="https://github.com/user-attachments/assets/74a0cdc6-c007-474c-a67b-fd12d484838f" />
This update fixes a bug where users could successfully pay invoices with expired payment terms. Now, the system automatically prevents payment attempts when the invoice's payment date has passed, ensuring accurate financial records and preventing incorrect payments. This improves the reliability of our invoicing process.
Original PR description
## Issue: Payment link should expire if payment is expired. #### Steps to reproduce: 1- Create a new quotation. 2- Set the expiry date in the past. 3- Open the action menu and generate a payment link. 4- Open the payment link and pay. Expected result: The payment should fail if the so is expired. opw-5478691 Forward-Port-Of: odoo/odoo#244061
This update fixes an issue where the system wasn't creating enough quality checks when receiving products with lot tracking enabled via the barcode scanner. The fix ensures that quality checks are generated for each unique lot scanned during a receipt process, improving inventory accuracy and quality control.
Original PR description
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking…
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking enabled and set a barcode reference. * Create a quality control point for this product with following configuration: * Operation: *Receipts* * Control per: *Quantity* * Control Frequency: *All* * Product: the previously created lot-tracked product. * Create a receipt for this product with a quantity of 6 and `mark as todo`. * Open the *Barcode* app and process the receipt. * Scan the product barcode. * Scan some quantity of the product with lot *LOT01* and put those units into a package(Put-In-Pack). * Scan the remaining quantity with lot *LOT02* and put those units into a different package(Put-In-Pack). * Click on **Quality Checks**. **Observed behavior:** * Only one quality check is created, even though the receipt contains two different lots that should each generate a quality check. **Cause:** * In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is equal to quantity(Demand). * During the `write` operation, quality checks are created only for move lines that are not picked, which prevents creating a quality check for each lot. * Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71 **Fix:** * Ensure that quality check points are generated correctly when validating products through the Barcode app using the Put in Pack option. --- opw-5405221
This update fixes errors in the SAF-T export process for Romanian companies when partner information (country or name) is missing. The changes ensure accurate registration number generation and prevent report errors, improving compliance for our Romanian clients.
Original PR description
Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918 Forward-Port-Of: odoo/enterprise#105020
This update resolves an issue where users without superuser privileges could encounter access errors when generating global invoices in the Mexican CFDI module. The fix ensures proper access control and cache management for the ir.sequence used in global invoice creation, preventing errors and intermittent failures.
Original PR description
**PROBLEM** 1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model. 2. There is an issue with the cache of the field…
**PROBLEM** 1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model. 2. There is an issue with the cache of the field `l10n_mx_edi_global_invoice_sequence_id`. (this is why problem can sometimes resolves itself on restarting the odoo instance). **STEP TO REPRODUCE** 1. Create 1 invoice with CFDI to public checked. 2. Goes to the list view for invoices, select the invoice, and apply the action "create global invoice" to it. 4. A access error may appear (depending on cache value). **CAUSE** 1. In `_get_global_invoice_cfdi_sequence()`, we get or create the ir.sequence used for global invoices. We are creating it with sudo(), so a user without sudo privilege can write to it. But, when we are retrieving a ir.sequence record that already exist, when don't use sudo(), this causes an access error for user without sudo privilege. 2. In `_get_global_invoice_cfdi_sequence()`, we try to get the computed field `l10n_mx_edi_global_invoice_sequence_id`. If it doesn't exist, we create a ir.sequence, but we forget to assign it to the field. Because we already trigger the compute method of the field by trying to access it, there is a None value in cache for it. This means we will always create a ir.sequence, despite one already existing for the company until the cache expires or the compute method is re-triggered. opw-5472552