Wednesday, December 31, 2025
3 changes · 18.0
Resolved issues and error corrections
This update prevents a payment error that occurred when invoices with missing due dates were processed. The fix ensures correct invoice calculations and payment processing by prioritizing invoice lines with due dates, resolving a potential disruption to financial operations.
Original PR description
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting`…
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting` module. - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`. - Go to `Invoices` and `create a new Invoice`. - Add one invoice line and set the `Payment Term` to the `newly created payment term`. - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden). - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`. - Now `Confirm the invoice` and `Click on Pay`. **Error:** `TypeError: '<' not supported between instances of 'datetime.date' and 'bool'` **Cause:** This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised. Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error. **Fix:** This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above. [1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703 [2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635 [3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305 [4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522 sentry-713241246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how Odoo handles web socket connections, particularly under heavy load. By delaying cursor acquisition attempts, the system reduces connection failures and improves overall responsiveness, especially when dealing with a large number of simultaneous users.
Original PR description
Benchmarking with 4k connected clients, 1 message per second. | | Message dispatching | Cursor analysis | |-- |-- | -- | | Before|<img width="600" alt="image" src="https://github.com/user-attachments/assets/f02e7efc-4611-4356-8bef-386ff2b0a7da" />|<img width="600" alt="2_current_implementation__cursor_analysis" src="https://github.com/user-attachments/assets/04dce96e-74a6-4f1b-9918-a6c61913e7c4" />| |After|<img width="600" alt="image" src="https://github.com/user-attachments/assets/a9463484-7f69-4fcb-a248-5692893a8893" />|<img width="600" height="997" alt="8_tweak_delay_both_sleep__cursor_analysis" src="https://github.com/user-attachments/assets/34a2c233-5c36-4597-a55b-cfb89a41efcf" />| Forward-Port-Of: odoo/odoo#241330
This update optimizes how product category information is loaded in the product screen, resolving a performance bottleneck. Previously, the loading process was slow and inefficient, particularly when dealing with many product categories. This change significantly improves the speed and responsiveness of the product screen, enhancing the user experience.
Original PR description
Before this commit, the product category info loading was done in O(n^2) time complexity due to nested loops. It caused performance issues when loading a large number of product categories. opw-5442894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr