Tuesday, May 19, 2026
17 changes · 19.0
Enhancements to existing features
The point of sale now avoids sending unnecessary creation notifications when no new records were added. This reduces needless background processing during routine actions like product scans, helping the POS stay more responsive without changing user workflows.
Original PR description
Previously, `loadData` always fired the `"create"` event for every model in a batch, even when all records in that batch were updates (`createdIds = []`). Any listener registered on `"create"` would then be invoked with an empty ID list.
For example, `computeDiscountProductIdsForAllRewards` in pos_loyalty is subscribed to `product.product` "create". When called with `{ ids: [] }`, it still iterated over every `loyalty.reward` and rebuilt its `all_discount_product_ids` array — a no-op that triggered reactive updates across all rewards on every product scan.
The fix guards the `triggerEvents("create", ...)` call behind a `createdIds.length` check, so the event only fires when at least one record was actually created.
opw-6091501
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe online shop now gives clearer feedback when a customer requests a unit of measure that is no longer available for a product. This helps avoid confusion after product setup changes and makes checkout issues easier to understand.
Original PR description
In some case, the requested uom might not be available (anymore) depending on the product latest changes. Followup on 4ac31e3545f009d0f96462f6a9098d5163ad521b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Changing a contact's country now correctly runs both the standard Odoo behavior and the Latin America localization behavior. This helps ensure contact information is updated consistently for companies using Latin American localization features.
Original PR description
Description of the issue/feature this PR addresses: The _onchange_country_id method in l10n_latam_base was not calling super(), causing the base method on res.partner to never execute when changing the country in contacts. Current behavior before PR: Only the l10n_latam_base method runs when changing country on a contact. The base _onchange_country_id is never called. Desired behavior after PR is merged: Both the base method and l10n_latam_base method run correctly. Fixes #264406
Google Gmail connection problems are still shown to users, but they are now recorded as warnings instead of errors in system logs. This reduces unnecessary error noise for support and monitoring teams without changing the user-facing behavior.
Original PR description
Currently, the logger prints an error message to the terminal when a response s not ok or a request exception is generated, and after this, a user error is raised to inform the users. Since this is non-blocking and the error warning shows to the users (by` UserError`), it’s better to log a warning here rather than an error. Sentry-6992264566
Fixes an issue where selecting all cells in a table header could trigger an error in the HTML editor. Users can now work with table headers more reliably without interruptions.
Original PR description
### Steps to Reproduce : - Add a table (e.g., /table). - Turn the first row into table header. - Select all the cells of the table header. - Traceback occurs. ### Purpose of this PR: - Selecting a table header row caused a `Cannot read properties of null (reading 'getBoundingClientRect')` error because the table plugin only looked for `td` elements. This PR replaces hardcoded `td` selectors with the `isTableCell` helper to handle both `td` and `th` elements. task-6220287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now download attached files even when the filename begins with a tab character, such as files extracted from certain ZIP archives. This prevents a browser error that blocked downloads from the chatter and improves reliability when handling imported documents.
Original PR description
**Steps to reproduce:** * Upload an XML file whose filename starts with a tab character (e.g. extracted from a ZIP that preserves the tab in the filename). * Go to Accounting > Vendor > Bills and import the XML file. * In the chatter, click the attached XML file to download it. **Observed behavior:** * A JavaScript error is raised in the browser console: `TypeError: invalid parameter format` * The file cannot be downloaded. **Cause:** * `PARAM_REGEXP` in `download.js` defines qdtext as `[\x20!\x23-\x5b\x5d-\x7e\x80-\xff]`, which excludes `\x09 (HT/tab)`. * Per RFC 2616, `qdtext = any TEXT` except `"`, and `TEXT` includes `LWS` which includes HT `(\x09)`, making `filename="\ttest.xml"` a valid Content-Disposition header. * The JS parser was incorrectly rejecting a valid header value. **Fix:** * Add `\x09` to the qdtext character class in `PARAM_REGEXP` in `download.js`, making the parser `RFC 2616` compliant. opw-6052996
The message composer no longer places an editable blank line inside the user's signature area. This prevents users from accidentally typing message content that gets hidden with the signature, making sent messages clearer and reducing confusion.
Original PR description
**Steps to reproduce:** - Go to the chatter of any record - Open the full composer - Empty line is present above the signature delimiter (`--`) - Adding text to this line will encapsulate it with the rest of the signature (and hide it by default in the message) **Issue:** Extra `<br>` was added to improve readability, but adding it this way (before the delimiter) can be confusing for the users as they can add text on what appears to be a normal empty line, that is actually hidden with the signature ellipsis. **Fix:** Moved the added `<br>` element outside the signature container for the full composer. The user can still find a way to modify the composer structure in a way that will hide part of the text (e.g. by typing just before the delimiter), but this limits the issue. related: https://github.com/odoo/odoo/commit/13a9c6f5010c3dee01aa0f66ed41b25f517a4a8c opw-6087042
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