Tuesday, May 19, 2026
10 changes · 19.0
Resolved issues and error corrections
This update resolves a performance issue related to how activity notifications are processed within the Odoo Enterprise system. The change optimizes notification handling, ensuring more reliable and efficient updates. This improves the overall responsiveness of the system when activities are modified.
Original PR description
Performance tests adjustements for the community counter-part
This update fixes an issue where POS order payments caused incorrect amounts to be displayed for customer balances. Specifically, a negative payment amount led to inflated remaining balances shown in the customer interface. This ensures accurate settlement amounts are presented to users.
Original PR description
When a customer paid off their account balance through a POS order, a negative pay_later amount was used. The condition `if order_due:` in `_compute_customer_due_total` evaluated to True for negative values, causing `customer_due_total` and `init_customer_due_total` to be set to a negative amount. This made `pos_orders_amount_due` on the partner go negative, which in turn inflated `remainingDue` in the frontend (remainingDue = totalDue - posOrdersAmountDue), showing a wrong amount in the "Settle due amount" button. opw-6187771
This update resolves a limitation in the sale commission report's query, allowing it to handle significantly larger AML IDs. By removing an unnecessary bit shift, the report now supports a much broader range of data, improving its overall performance and scalability. This change ensures the report continues to function correctly with increasing data volumes.
Original PR description
The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs.…
The combined query for sale.commission.achievement.report originally performs several bitwise shifts, starting with the max AML ID. This is done to create a composite number ID for the combined IDs. `MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id <<10` This shifts the max aml.id 40 bits to the left. Example: Let's say MAX(aml.id) = 1; we will set the other variables to 1, as they often have little impact on the total size of the number. 1 << 20 = 1048576 1048576 | 1 = 1048577 1048577 << 10 = 1099512676352 1099512676352 | 1 = 1099512676353 1099512676353 << 10 = 1152922604119523328 With this format, the highest guaranteed AML ID this query can handle is under 838,861. The last 10-bit shift is unnecessary and increases the result. If we remove the last shift, the AMD ID this query can handle becomes much higher. `MAX(aml.id)::bigint <<20) | max(rules.id)::bigint <<10 | rules.user_id` | | AML Max | RULES.ID Max |RULES.USER_ID Max| | --------------------- | ------ | ------ | ------ | | Before | 838,861 | 1,048,576 | 1,024 | | After | 858,993,459 |1,048,576 | 1,024| opw-6124026
This update resolves an issue where order synchronization with Lazada was failing due to errors when package data was missing. The fix prevents the system from attempting to sync when no matching package lines are found, ensuring smoother and more reliable order processing. This improves the overall efficiency of Lazada order integration.
Original PR description
orders can omit package data in the API payload if the package id doesn't match. When a picking still had a package_extern_id, filtering order_items by that id produced an empty list, and max() on the resulting timestamps raised ValueError and blocked order sync. Return early when no matching package lines exist so sync can continue. taskId - 6195507
This update fixes a labeling issue within the fleet vehicle module. The previous labels incorrectly indicated deductibility rates; this change ensures the labels accurately reflect the non-deductible portions, improving clarity and accuracy for financial reporting.
Original PR description
The "Deductibility Rates" and "Deductibility (%)" labels are wrong for vehicles as they are supposed to represent the non-deductible part. This commit fixes these labels. task-6121629
This update removes a problematic 'Create Ticket' action from the WhatsApp sidebar in Discuss. Previously, clicking this action caused an error due to a missing variable. This fix ensures a smoother user experience for WhatsApp conversations.
Original PR description
The 'Create Ticket' action was incorrectly visible in the sidebar actions of WhatsApp conversations in Discuss. Clicking it caused a traceback because `owner.root` is not defined in the sidebar action context. This commit removes the action from sidebar actions. Task-[6220037](https://www.odoo.com/odoo/project/1519/tasks/6220037)
This update fixes a potential error that could display a traceback when a spreadsheet wasn't available. The change prevents this by handling server errors directly, eliminating the need for template modifications and simplifying the process. This improves the overall stability and user experience of the spreadsheet functionality.
Original PR description
The fix suggested in #81276 did not account for other spreadsheet models than a document as it required some modification in the component template. The same logic should then have been forwarded to other models (quality.check for instance] but that process is error prone. This revision changes the approach by handling the server error inside the abstract action so that no template modification is required. task-6208222
This update ensures that all text within the MRP MPS component of Odoo Enterprise is properly prepared for translation. Previously, placeholder text was not translatable, which limited the software's ability to be localized for different languages and regions. This change improves the overall internationalization and usability of the system.
This update fixes an issue where Knowledge articles appeared narrow when printed on large screens. The fix specifically targets the Knowledge editor's form view, preventing a default CSS rule from causing a constricted layout. Now, articles print correctly in a readable format when exported or printed.
Original PR description
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size. See: ```scss .o_form_view.o_xxl_form_view { .o_form_view_container {…
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.
See:
```scss
.o_form_view.o_xxl_form_view {
.o_form_view_container {
width: 1px; /* List view needs a width value to recompute the size correctly */
}
}
```
However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.
Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"
=> The article is rendered in a very narrow column.
To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.
Task-5999878
Forward-Port-Of: odoo/enterprise#103259This update prevents unnecessary delays and UI clutter when syncing with unreachable databases. Previously, the synchronization wizard would display errors for every database, and the system would waste up to 15 seconds attempting to create API keys. Now, the system skips creating API keys for unreachable databases, improving sync speed and user experience.
Original PR description
#### The aim of this commit is to: - avoid cluttering the user UI with "obvious" error. - avoid wasting up to 15s trying to create the key if we don't get any response. #### Context: When a db is unreachable, trying to create an api-key on it will result in an error. #### Before this commit: - The wizard showing the result of the synchronization would show the error for every single databases in which it encounters that error. If there are a lot, it would bloat the result. - An unresponsive db would waste 15s of our sync time in a synchronized process. If that happens multiple times, we could end up a lot of time waiting for no reason. #### After this commit: We don't try to create an api key for unreachable databases. task-id: [5945269](https://www.odoo.com/odoo/project.task/5945269) - follow up