Friday, January 9, 2026
12 changes · 17.0
Enhancements to existing features
This update optimizes the process of exporting the general ledger as an Excel file. Previously, large exports could cause performance issues and errors due to excessive memory usage. This change implements batch processing to significantly improve export speed and stability, ensuring reliable reporting.
Original PR description
Batch the xlsx export of the general ledger to avoid memory errors task-5476982
Resolved issues and error corrections
This update resolves a potential issue where payment processing with Stripe would fail due to timeouts when API requests took longer than 60 seconds. The code now logs a warning if a timeout occurs, preventing failed payments and improving the reliability of the payment provider.
Original PR description
When the user connect with Stripe in the payment provider and an API request takes longer than 60 seconds then a ReadTimeout error will occur. Line 1:…
When the user connect with Stripe in the payment provider and an API request takes longer than 60 seconds then a ReadTimeout error will occur.
Line 1: https://github.com/odoo/odoo/blob/29a40a30f3bf7a4a3a205e54fb84e569691d961f/addons/payment_stripe/models/payment_provider.py#L413-L418
Traceback on sentry:
```
TimeoutError: The read operation timed out
File "urllib3/connectionpool.py", line 445, in _make_request
six.raise_from(e, None)
File "<string>", line 3, in raise_from
# Permission is hereby granted, free of charge, to any person obtaining a copy
File "urllib3/connectionpool.py", line 440, in _make_request
httplib_response = conn.getresponse()
File "http/client.py", line 1375, in getresponse
response.begin()
File "http/client.py", line 318, in begin
version, status, reason = self._read_status()
File "http/client.py", line 279, in _read_status
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
File "socket.py", line 705, in readinto
return self._sock.recv_into(b)
File "ssl.py", line 1274, in recv_into
return self.read(nbytes, buffer)
File "ssl.py", line 1130, in read
return self._sslobj.read(len, buffer)
ReadTimeoutError: HTTPSConnectionPool(host='stripe.api.odoo.com', port=443): Read timed out. (read timeout=60)
File "requests/adapters.py", line 439, in send
resp = conn.urlopen(
File "urllib3/connectionpool.py", line 755, in urlopen
retries = retries.increment(
File "urllib3/util/retry.py", line 532, in increment
raise six.reraise(type(error), error, _stacktrace)
File "six.py", line 719, in reraise
raise value
File "urllib3/connectionpool.py", line 699, in urlopen
httplib_response = self._make_request(
File "urllib3/connectionpool.py", line 447, in _make_request
self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
File "urllib3/connectionpool.py", line 336, in _raise_timeout
raise ReadTimeoutError(
ReadTimeout: HTTPSConnectionPool(host='stripe.api.odoo.com', port=443): Read timed out. (read timeout=60)
File "odoo/http.py", line 2134, in __call__
response = request._serve_db()
File "odoo/http.py", line 1710, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1737, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1938, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/sale/wizard/payment_provider_onboarding_wizard.py", line 31, in add_payment_methods
return super().add_payment_methods()
File "addons/payment/wizards/payment_onboarding_wizard.py", line 141, in add_payment_methods
return self._start_stripe_onboarding()
File "addons/sale/wizard/payment_provider_onboarding_wizard.py", line 36, in _start_stripe_onboarding
return self.env.company._run_payment_onboarding_step(menu_id)
File "addons/payment/models/res_company.py", line 51, in _run_payment_onboarding_step
return stripe_provider.action_stripe_connect_account(menu_id=menu_id)
File "home/odoo/src/custom/trial/saas_payment_stripe/models/payment_provider.py", line 87, in action_stripe_connect_account
return super().action_stripe_connect_account(menu_id)
File "addons/payment_stripe/models/payment_provider.py", line 152, in action_stripe_connect_account
connected_account = self._stripe_fetch_or_create_connected_account()
File "home/odoo/src/custom/trial/saas_payment_stripe/models/payment_provider.py", line 184, in _stripe_fetch_or_create_connected_account
connected_account = super()._stripe_fetch_or_create_connected_account()
File "addons/payment_stripe/models/payment_provider.py", line 326, in _stripe_fetch_or_create_connected_account
return self._stripe_make_proxy_request(
File "addons/payment_stripe/models/payment_provider.py", line 414, in _stripe_make_proxy_request
response = requests.post(url=url, json=proxy_payload, timeout=60)
File "requests/api.py", line 119, in post
return request('post', url, data=data, json=json, **kwargs)
File "requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "requests/sessions.py", line 544, in request
resp = self.send(prep, **send_kwargs)
File "requests/sessions.py", line 657, in send
r = adapter.send(request, **kwargs)
File "requests/adapters.py", line 529, in send
raise ReadTimeout(e, request=request)
```
To handle this situation, the code has been updated to ensure that if the system takes more than 60 seconds to connect with Stripe then raises a logger warning.
sentry-4506249274
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue that prevented users from successfully editing reports within the Studio mode. The system was incorrectly splitting report keys, leading to an error message. The fix ensures the system correctly handles report copying by limiting the number of values unpacked, allowing for seamless report editing.
Original PR description
Currently, raise an error message in the report editor when trying to edit any reports in the studio mode. error message: too many values to unpack (expected 2)) When we modify a report, the system…
Currently, raise an error message in the report editor when trying to edit any reports in the studio mode. error message: too many values to unpack (expected 2)) When we modify a report, the system tries to make a copy of it. To make this copy, the system needs to provide certain details like the name, mode key etc . At that time system tries to assign multiple values instead of two at this point [1] because the 'key' passed to do a copy of the report is [2] split by '.' as we see in [1] which leads to multiple values instead of two. link [1]: https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/odoo/addons/base/models/ir_ui_view.py#L102 link [2]: https://github.com/odoo/enterprise/blob/34a042bb196273c34cd163f4c43bbd858664b7dc/web_studio/controllers/report.py#L337 To resolve the issue, Add limiting into split, To ensure that there are only two elements in the resulting list, which can unpacked into two (first is module, second is view_id) variables to prevent error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that caused errors when users modified existing reports through the Web Studio interface. By adding error handling, the system now gracefully displays a user-friendly message instead of crashing, improving the report editing experience.
Original PR description
Currently, the error is generated when the client is trying to modify the view of an existing report through Web Studio. Steps to reproduce: - Install the 'web_studio' module and any other module…
Currently, the error is generated when the client is trying to modify the view of an existing report through Web Studio. Steps to reproduce: - Install the 'web_studio' module and any other module that has report options available for example here we are using the 'account' module. - Open 'Studio' in Invoicing and (Turn on the debugger mode) - Then go to 'Reports' and open any existing report. - Click on 'More' option and then click on the '</>Qweb Views' button. - Open the view and remove everything except the first and the last line, Save it now and go back to the report you modified the error will be generated. ```IndexError: list index out of range``` To resolve the issue, we will add a try-except block at [1] to handle errors. This will ensure that if an error occurs when accessing an edited report, it will raise a user error message and this error message will be seen in the report editor. link [1]: https://github.com/odoo/enterprise/blob/6c538b5ba63be936120f38c90445dfbb2e65a625/web_studio/controllers/report.py#L583-L584 sentry-4650493111
This update fixes a bug that prevented users from successfully editing reports within Web Studio due to invalid syntax in the Qweb architecture. By adding a safety check, the system now validates report templates, preventing errors and ensuring a smoother editing experience. This improves the reliability of the reporting feature.
Original PR description
An error is generated when editing reports with an incorrect value or syntax. Steps to reproduce: (Edit a report of the 'sale' module to generate an error as an example): - Install an 'sale_management' and 'web_studio' module. - Navigate to Settings / Technical / User Interface / Views. - Open 'report_saleorder_document', Edit in 'Qweb Architecture' with an incorrect syntax of like <t t-call='handelux_A4_leaflet_base_template'/>. - Open a Sales, open a studio mode, and click on 'Reports'. - Try to open any report. ```ValueError: Invalid template id: 'handelux_A4_leaflet_base_template'``` To resolve the issue, we will add a try-except block at [1] to handle errors. This will ensure that if an error occurs, it will raise a validation error. link [1]: https://github.com/odoo/enterprise/blob/3de380edfe66f65c220f1d83edbac8009793ef0b/web_studio/controllers/report.py#L592 sentry-5636723770
This update resolves an error that occurred when uploading incorrect CFDI XML files to generate invoices. The system was attempting to retrieve data not present in the file, causing a 'KeyError'. The fix ensures the system gracefully handles missing data by returning a 'None' value, preventing the error and allowing invoice generation to proceed.
Original PR description
Currently, an error occurs when uploading a CFDI XML file to generate an invoice. Step to produce: - Install the 'l10n_mx_edi' module. - Navigate to Accounting > Customers > Invoices. - Upload the incorrect CFDI XML file.(use this [1] XML file to reproduce a issue ) Link[1]: https://drive.google.com/file/d/1nljsTCNsNjHyacikZx0rApk5YQcAQPm-/view?usp=drive_link ```KeyError: 'usage'``` An error occurs when attempting to generate CFDI values in an invoice by uploading an incorrect XML file and the system tries to retrieve a 'usage' from the 'cfdi_vals' at [2] which is not available because the XML file is not correct. Link [2]: https://github.com/odoo/enterprise/blob/641dcfe7a74b3e9a987779493ed2c3612a3202b1/l10n_mx_edi/models/account_move.py#L2566 To resolve the issue return a None value if cfdi values are not available in XML file. Sentry-5658142430
This update corrects a bug in Odoo's automation engine that caused delays in tasks being created when timesheets exceeded allocated time. The fix ensures that dependent computed fields are correctly recomputed after a pre-filter condition is applied, preventing inconsistent behavior and improving task creation reliability.
Original PR description
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323 When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled…
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323
When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled afterwards For example, if a rule pre-filters on field B (which depends on A), computing A should not clear the compute flag of B
### Issue:
In some automation rules, computed fields must be processed in a specific order (e.g., `effective_hours` -> `remaining_hours`)
However, if `remaining_hours` is referenced in the automation `Before Update Domain`, its compute flag may be incorrectly cleared, preventing the proper recomputation chain
This results in inconsistent behavior, such as delays in activities being created when timesheets exceed allocated time
### Cause:
The automation engine flushes fields referenced in the `Before Update Domain`, but does not restore their compute flags afterward Thus dependent fields are not recomputed as expected
### Steps to reproduce:
1. Enable Debug Mode
2. Create an Automation Rule
-- Name: Time Exceeded
-- Model: Task
-- Trigger: On Save
-- Before Update Domain: [("remaining_hours", ">=", 0)]
-- Apply on: [("remaining_hours", "<", 0)]
4. Create a Project with Timesheets
5. Create a Task inside the Project
6. Set Allocated Time to 10h
7. Use the Start button to record 11h (No activity appears in chatter)
8. Do the same again (Activity appears only after the second exceed) Before the fix, there is always a delay because the recomputation chain is broken
### Tickets:
18.0: opw-4409744
17.0: opw-5237430This update fixes an issue where discounts applied to repair quotations weren't correctly carried over to the linked sale order lines. The fix removes a faulty process that was resetting the discount calculation, ensuring discounts are accurately reflected in the final sale order. This improves the accuracy of pricing and reporting for repair services.
Original PR description
**Steps to reproduce:** * Install the **Repair** module with demo data. * From Setting -> enable 'Discounts' and 'Pricelists' * From the home screen, search for Pricelist and open it. * Open the…
**Steps to reproduce:** * Install the **Repair** module with demo data. * From Setting -> enable 'Discounts' and 'Pricelists' * From the home screen, search for Pricelist and open it. * Open the default USD pricelist and go to Configuration → `Show public price & discount to the customer` * Open the *Repair* app. * Create a **Repair Order with parts**. * Click **Create Quotation** button from the repair order. * In the quotation, order line and set a **discount**. * Return to the repair order using the **Repairs** smart button. * Confirm the repair order, then **Start repair** and **End repair** order. **Observed behavior:** * The discount added on the quotation line disappears from the linked sale order line. **Cause:** * The `discount` field on `sale.order.line` is computed by `_compute_discount`, which `depends` on `product_id`, `product_uom`, and `product_uom_qty`. When `product_uom_qty` is written during `action_repair_done`, the compute method is triggered and the `discount` is recalculated. https://github.com/odoo/odoo/blob/49169c4c4fec57d78cd82c4c9366de9d69540e6a/addons/repair/models/repair.py#L457 **Fix:** * Remove the for loop that calls `write()` on the sale order lines, as it is functionally incorrect and causes the discount to be reset. --- opw-5352567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where invoices generated with complex certificates (multiple similar RDNs) failed validation by external authorities. The fix ensures the issuer is correctly generated by prioritizing RDNs, improving compliance with Spanish tax regulations. This prevents invoice errors and potential delays.
Original PR description
When a certificate contains multiple RDNs of the same type (for example several OU entries), the generated issuer is incorrect. This happens because the current implementation relies on a dictionary to sort the RDNs, causing duplicate keys to be overwritten. Steps to reproduce: - Create a certificate with multiple OU RDNs - Upload the certificate in Odoo - Generate the Facturae EDI document - Validate it using official tools: https://face.gob.es/es/facturas/validar-visualizar-facturas https://valide.redsara.es/valide/ejecutarValidarFirma/ejecutar.html The validation fails because the issuer is incorrect. This commit fixes the issue by sorting RDNs using a priority-based list, ensuring all RDNs are preserved and ordered correctly. opw-5408225 opw-5380996 opw-5253287
This update corrects a mistake in the French language version of Odoo's tax reporting functionality. Specifically, an aggregation error in box 15_1 was identified and resolved. This ensures accurate tax calculations and reporting for French businesses using the Odoo system.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/869f80b466ec2246f27e11fa823eb32ac664fb01 we made a mistake in the box 15_1. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem preventing connections to IAP Codaclean, which is essential for accurate VAT reporting. The issue was caused by a missing parameter in the connection process. This fix ensures seamless integration with Codaclean, improving compliance and data accuracy.
Original PR description
Connections to IAP Codaclean are failing because of missing `enterprise_number` param. no-task-id
This update resolves a problem where Odoo was incorrectly handling multiple tax repartition lines, resulting in broken UBL files used for electronic invoicing. The fix ensures that all tax lines are properly processed, generating valid UBL files for international trade compliance. This prevents errors in export processes.
Original PR description
When dealing with multiple repartition lines on a tax, only the first one is considered leading to a broken ubl file. Introduced by: f35aefed9347f68b6957ec790c129235a294882c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr