Daily updates from Odoo
Tuesday, July 14, 2026
382 changes
11 changes
New functionality added to Odoo
This pull request updates the Odoo localization files to include translations for the new PayU payment method. This addition expands Odoo's payment options, supporting a wider range of customers and payment gateways. It’s a standard I18N update to ensure the system is properly localized for this new functionality.
Original PR description
Forward-Port-Of: odoo/odoo#275865
Enhancements to existing features
This update brings the Owl library, a key component of our website's image zooming functionality, to version 2.8.4. This includes a fix to prevent lost image renders and support for running the library with Node.js, enhancing our website's performance and flexibility.
Original PR description
- [FIX] runtime: don't lose coalesced renders - [IMP] loadable with nodejs See https://github.com/odoo/owl/commits/owl-2.x/ for more details Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275568
This update enhances the error message displayed when issues arise with leave validity calculations. Previously, troubleshooting required manual investigation, but now customers and support teams can quickly identify the root cause of leave allocation problems. This improves user experience and reduces support time.
Original PR description
The current message is pretty useless as of now when a lot of leaves are being written to, notably when creating a public holiday, which sets the state of all the leaves overlapping the public holiday's day to be reevaluated, and if an error occurs, you have to go through every employee's leave allocation and leaves taken to hopefully find one who might have to many days taken/not enough allocated. This extra information will be a huge QOL improvement, for the customer who will be able to troubleshoot his issue himself more easily, but also for our support team as the only way to debug those kind of issues now is to put a breakpoint there and see what employee has an issue. opw-4411999 Forward-Port-Of: odoo/odoo#272412 Forward-Port-Of: odoo/odoo#200376
Resolved issues and error corrections
This update fixes an issue where the quantity of items delivered was incorrectly calculated after a refund was processed in the point-of-sale system. The change ensures that the system accurately reflects the net quantity of items delivered, preventing double-counting of refunds. A new test has been added to ensure this issue doesn't reappear.
Original PR description
Step to reproduce: - create a SO with a order line - settle it in pos, notice in SO line, qty_delivered is 1 - refund the pos order - notice, in SO qty_delivered is -1 , not 0 Cause: - After commit [1] , `pos_order_line_ids` now includes order and refund lines - while the `_prepare_qty_delivered` relied on fact that refund lines are not part of `pos_order_line_ids` - due to this, quantity was reduced twice (refund amount are considered twice) [1] https://github.com/odoo/odoo/commit/a12db424a6986a58d1a328fd311078994ac17aee Fix: - in the compute, we now seperate refund and order lines and thus compute works perfectly opw-6290161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274952 Forward-Port-Of: odoo/odoo#269996
This update ensures that the Pos Cashmatic module's text is properly translated into different languages. By adding the module to the translation files (.weblate.json), the system will now display the correct text for users around the world. This improves the user experience for international customers.
Original PR description
This commit add the pos_cashmatic module inside the .weblate.json file so that the srings are translated. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275863
This update resolves an issue where the order tour would intermittently fail to complete due to a race condition when navigating to pinned messages. The fix ensures the tour waits for the message to fully scroll before proceeding, preventing errors and improving the user experience. This enhances the reliability of the tour feature.
Original PR description
Jumping to the pinned message highlights it and asynchronously scrolls it into view. On a slow browser that scroll can land right after the tour scrolls to the bottom and pull the thread back up to the pinned message. The load-newer observer callback, which awaits the highlight scroll before re-checking visibility, then finds the bottom sentinel hidden and drops the fetch of the following messages, so the final :count(60) step never matches and times out. Wait for the pinned message to be scrolled into view and for its highlight to clear (its scroll is then finished) before scrolling to the bottom, so the jump scroll no longer competes. https://runbot.odoo.com/odoo/error/941509 Forward-Port-Of: odoo/odoo#275289
This update resolves an issue where opening a self-sent email through the Gmail add-in would trigger an error. The fix ensures that users can reliably open and manage emails sent directly to their own addresses without encountering this technical problem. This improves the usability of the email functionality.
Original PR description
Bug === If we email ourselves, and open the Gmail addin on it, then an error is raised. Task-6375862 Forward-Port-Of: odoo/odoo#275810
This update resolves a technical glitch in the mass mailing module that was causing misleading error messages. The fix ensures that errors related to component loading are properly masked, improving the stability and reliability of the mass mailing functionality. This change primarily impacts the backend processes.
Original PR description
Commit [1] introduced an erroneous `!` operator before status, that would throw loading errors even if the component was already destroyed (those errors should be masked). [1]: https://github.com/odoo/odoo/commit/51c7846f99eb061a1d71ca5d9967f5b01f5551a1 Forward-Port-Of: odoo/odoo#275785
This update resolves an issue where triple-clicking within inline editable text boxes in the HTML editor caused the selection to extend beyond the intended area. The fix ensures that triple-clicks accurately select and highlight the intended content, improving the user experience and editor functionality. This change enhances the consistency and reliability of the HTML editor.
Original PR description
Problem: Triple-clicking inside an inline `contenteditable="true"` element causes the selection to extend outside of it. Cause: Inline `contenteditable="true"` elements are not considered when looking for the closest block boundary, allowing the browser selection to expand beyond the editable content. Solution: Treat `contenteditable="true"` elements as block boundaries when searching for the closest block. Steps to reproduce: - Add an inline `contenteditable="true"` element inside an editable area. - Triple-click inside it. - Observe that content outside the `contenteditable` element is also selected. task-6255094 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267487
This update ensures that all invoices sent via Peppol are regularly checked for validity, regardless of whether they are sent in batches or individually. Previously, this check was only performed manually, leading to potential issues with Peppol compliance. This change improves the reliability and accuracy of our Peppol invoice processing.
Original PR description
If you have a partner that wasn't on Peppol. If you only do batch sending, we never re-check its validity. You need to do it by hand, or open explicitely the send&print for an invoice for this customer. We should simply do that check in every case, in batch or in manual sending. task-6296017 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273121
This update fixes a visual issue in the API keys kanban view where scope and expiration information for scoped keys were displayed together as a single line. The change now presents these details as separate lines, improving readability and clarity for users managing API keys. This ensures all key information is easily accessible.
Original PR description
The API keys kanban rendered the "Scope:" and "Expires on:" hints as two adjacent inline <small> elements. For a scoped key both are visible, so they were displayed stuck together, e.g. "Scope: rpcExpires on: ...". Render each hint as a block so they stack on their own lines. Keys without a scope are unaffected since the scope hint stays hidden. Description of the issue/feature this PR addresses: Current behavior before PR: <img width="980" height="414" alt="image" src="https://github.com/user-attachments/assets/6cd8b338-1d2e-4abb-a90b-03218aaef941" /> Desired behavior after PR is merged: <img width="979" height="389" alt="image" src="https://github.com/user-attachments/assets/83ffa680-ffb8-415f-af3f-8e53cb8e8351" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275869
15 changes
New functionality added to Odoo
This pull request updates the Odoo localization files to include translations for the PayU payment method. This addition allows Odoo users to accept payments through PayU, expanding payment options and supporting international business operations. The change is part of a broader effort to improve localization and support new payment gateways.
Original PR description
Forward-Port-Of: odoo/odoo#275865
Enhancements to existing features
This update brings the Owl library, a key component of our website, to the latest version (2.8.4). This improves performance and allows us to utilize modern Node.js development practices, ensuring a smoother user experience and future flexibility. The update also resolves a previous issue related to rendering, preventing data loss.
Original PR description
- [FIX] runtime: don't lose coalesced renders - [IMP] loadable with nodejs See https://github.com/odoo/owl/commits/owl-2.x/ for more details Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275568
Resolved issues and error corrections
This update fixes an issue where down payment invoices generated from POS wouldn't correctly display the original line name. Previously, the system incorrectly used the sale order line's name instead. Now, down payment invoices maintain their own unique line names, ensuring accurate invoice reporting and customer clarity. This resolves a previous bug impacting POS transaction accuracy.
Original PR description
When a POS line comes from a sale order, its invoice line name is overridden with the source sale order line's name. When a down payment is invoiced directly from the POS, the invoice is generated before the down payment POS line is linked to its sale order line, so sale_order_line_id is still empty and the override resolved to an empty recordset, setting the invoice line name to False. Only override the name when a sale order line is actually set, so the down payment line keeps its own name. opw-6305649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274000
This update resolves a technical error that occurred when users opened the Gmail add-in after sending an email to themselves within Odoo. The fix ensures that self-sent emails can now be reliably accessed and opened through the Gmail integration, improving usability for internal communications.
Original PR description
Bug === If we email ourselves, and open the Gmail addin on it, then an error is raised. Task-6375862 Forward-Port-Of: odoo/odoo#275810
This update fixes a bug that occurred when navigating the order tour on slower browsers. Specifically, jumping to a pinned message caused a scroll race, leading to timeouts and the tour failing to complete. The fix ensures the tour waits for the pinned message to fully scroll before proceeding, improving navigation reliability.
Original PR description
Jumping to the pinned message highlights it and asynchronously scrolls it into view. On a slow browser that scroll can land right after the tour scrolls to the bottom and pull the thread back up to the pinned message. The load-newer observer callback, which awaits the highlight scroll before re-checking visibility, then finds the bottom sentinel hidden and drops the fetch of the following messages, so the final :count(60) step never matches and times out. Wait for the pinned message to be scrolled into view and for its highlight to clear (its scroll is then finished) before scrolling to the bottom, so the jump scroll no longer competes. https://runbot.odoo.com/odoo/error/941509 Forward-Port-Of: odoo/odoo#275289
This update resolves a hidden error in the mass mailing module that was causing loading problems, even when the component was already finished. The fix ensures smoother operation and prevents potential disruptions to email campaigns.
Original PR description
Commit [1] introduced an erroneous `!` operator before status, that would throw loading errors even if the component was already destroyed (those errors should be masked). [1]: https://github.com/odoo/odoo/commit/51c7846f99eb061a1d71ca5d9967f5b01f5551a1 Forward-Port-Of: odoo/odoo#275785
This update resolves an issue where triple-clicking within inline editable content caused the selection to extend beyond the intended area. The fix ensures that triple-clicks accurately select the inline content, improving the user experience within the HTML editor.
Original PR description
Problem: Triple-clicking inside an inline `contenteditable="true"` element causes the selection to extend outside of it. Cause: Inline `contenteditable="true"` elements are not considered when looking for the closest block boundary, allowing the browser selection to expand beyond the editable content. Solution: Treat `contenteditable="true"` elements as block boundaries when searching for the closest block. Steps to reproduce: - Add an inline `contenteditable="true"` element inside an editable area. - Triple-click inside it. - Observe that content outside the `contenteditable` element is also selected. task-6255094 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267487
This update ensures that all invoices sent via Peppol are regularly checked for validity, regardless of whether they are sent in batches or individually. Previously, batch sending didn't automatically verify partner status, requiring manual intervention. This change enhances the reliability of Peppol invoice processing and reduces potential errors.
Original PR description
If you have a partner that wasn't on Peppol. If you only do batch sending, we never re-check its validity. You need to do it by hand, or open explicitely the send&print for an invoice for this customer. We should simply do that check in every case, in batch or in manual sending. task-6296017 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273121
This update ensures that the Pos Cashmatic module's text is properly translated into other languages. By adding the module to the translation files, the system will now display the correct text for users in different regions. This improves the user experience and expands the module's accessibility.
Original PR description
This commit add the pos_cashmatic module inside the .weblate.json file so that the srings are translated. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275863
This update fixes a visual issue in the API keys kanban view where scope and expiration information for scoped keys were displayed together as one line. The change now presents these details as separate blocks, improving readability and clarity for users managing API keys. This ensures all key information is easily accessible.
Original PR description
The API keys kanban rendered the "Scope:" and "Expires on:" hints as two adjacent inline <small> elements. For a scoped key both are visible, so they were displayed stuck together, e.g. "Scope: rpcExpires on: ...". Render each hint as a block so they stack on their own lines. Keys without a scope are unaffected since the scope hint stays hidden. Description of the issue/feature this PR addresses: Current behavior before PR: <img width="980" height="414" alt="image" src="https://github.com/user-attachments/assets/6cd8b338-1d2e-4abb-a90b-03218aaef941" /> Desired behavior after PR is merged: <img width="979" height="389" alt="image" src="https://github.com/user-attachments/assets/83ffa680-ffb8-415f-af3f-8e53cb8e8351" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275869
This update fixes a visual glitch where an empty AI conversation thread would briefly flash on the screen. The change ensures the AI thread start message only appears after the thread has fully loaded, aligning with the standard display of regular discussion channels. This improves the user experience and prevents a distracting visual issue.
Original PR description
Only display the AI thread start message once the thread has finished loading, matching the behavior of regular Discuss channels and preventing a brief flash of the empty conversation. Update the AI-specific `showStartMessage` implementation to respect the base Thread loading state instead of always displaying the start message for AI channels. Enterprise PR : https://github.com/odoo/enterprise/pull/122808 task-6352578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update significantly speeds up batch payments processing, particularly when dealing with large numbers of partners. The change resolved a previous memory issue that caused errors, allowing for faster and more reliable processing of invoices. This improves overall system performance and stability.
Original PR description
### Description: Processing batch payments for multiple invoices triggers the `_increase_rank` method across numerous partners. Previously, this could lead to Out-Of-Memory (OOM) errors in databases with extensive partner hierarchies (parent/child relationships), primarily due to cascaded writes triggered by `_commercial_sync_to_descendants`. This commit optimizes the rank increment process, significantly reducing both memory consumption and execution time. ### Benchmark: | Partner Count | Time Before | Time After | Memory After | |---------------|-------------|------------|--------------| | 191,946 | 2 min | 47s | 111 Mb | | 393,509 | OOM | 1 min 45 | 216 Mb | ### Reference: opw-5152687 Forward-Port-Of: odoo/odoo#275718 Forward-Port-Of: odoo/odoo#259334
This update streamlines the process of logging out employees in the Point of Sale system. By reducing the idle timeout, the system now automatically logs out staff more quickly, improving efficiency and security. This change was implemented as a bug fix to address a reported delay in employee logout.
Original PR description
Reduce idletimeout task id: 6374370 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275081
A recent update introduced an access error for users with Attendance admin rights but lacking access to employee records when viewing overtime rulesets. This fix restricts the visibility of a new 'stat' button to authorized users, preventing the error while maintaining the feature for those with appropriate permissions. This ensures all users can access the necessary functionality.
Original PR description
**Steps to reproduce:** 1. Install the **Attendance** app in saas-19.2 with demo data. 2. Log in as a user who has **Administrator** rights in the Attendance app but no access rights in the Employees…
**Steps to reproduce:**
1. Install the **Attendance** app in saas-19.2 with demo data.
2. Log in as a user who has **Administrator** rights in the Attendance app but no access rights in the Employees app.
3. Go to **Attendance → Configuration → Overtime Rulesets**.
4. Open any overtime ruleset.
An `AccessError` is raised:
```
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 3373,
in check_access
raise result[1]()
odoo.exceptions.AccessError: You are not allowed to access
'Employee Record' (hr.version) records.
This operation is allowed for the following groups:
- Employees/Administrator
- Employees/Officer: Manage all employees
Contact your administrator to request access if necessary.
```
**Issue:**
A new feature introduced an employee count stat button on `hr.attendance.overtime.ruleset` in [v19.2](https://github.com/odoo/odoo/pull/236555/changes).
Users who have administer right in Attendance app but do not have access to Employee records trigger an access error when opening the ruleset.
**Solution:**
The fix restricts the visibility of the [Stat button ](https://github.com/odoo/odoo/blob/7c6f31d730304bca3f6c996800e76d1e40ce4adf/addons/hr_attendance/views/hr_attendance_overtime_rule_views.xml#L114)to users with the required Employee groups, preventing the access error while keeping the feature available for authorized users.
opw- 6358550
upg- 4449776
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#275320Features or functions removed from Odoo
This update simplifies the restaurant POS system by standardizing payment method naming conventions. The team has replaced older, snake_case methods with camelCase equivalents, improving code consistency and maintainability. This change ensures smoother integration and future development of the restaurant POS module.
Original PR description
In this commit: - Use the new method names in the payment adjustment flow. - Replace deprecated snake_case methods with their camelCase equivalents for payment lines, payment terminals, and order totals. Task:6049128 Forward-Port-Of: odoo/odoo#271792
15 changes
New functionality added to Odoo
This pull request updates the Odoo localization files to include translations for the 'payment_payu' feature. This addition allows Odoo users to integrate with PayU, a popular payment gateway, expanding payment options for their business. It’s a standard I18N update to support new functionality.
Original PR description
Forward-Port-Of: odoo/odoo#275865
Enhancements to existing features
This update improves the performance and reliability of our website's image galleries by upgrading the Owl library to the latest version (2.8.4). Specifically, it fixes a bug that caused image renders to be lost and adds support for running the library with Node.js, enhancing flexibility.
Original PR description
- [FIX] runtime: don't lose coalesced renders - [IMP] loadable with nodejs See https://github.com/odoo/owl/commits/owl-2.x/ for more details Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275568
Resolved issues and error corrections
This update resolves a bug where employee working schedules weren't consistently updating with new version changes, leading to inaccurate attendance visualizations. The fix ensures schedules are synchronized between employee and resource records, preventing issues like incorrect unavailable time slots in the Attendance Gantt view. This improves data accuracy for employee scheduling.
Original PR description
Steps to reproduce: 1. Create a new version on an employee with a future start date 2. Ensure the new version has a different working schedule 3. After the new version becomes active, observe that…
Steps to reproduce: 1. Create a new version on an employee with a future start date 2. Ensure the new version has a different working schedule 3. After the new version becomes active, observe that the working schedule on the employees record is different from the one on the employee's resource record Every employee has an associated resource record associated with them. Normally, the employee's working schedule (`hr_employee.resource_calendar_id`) should always be in sync with their associated resource record (`hr_employee.resource_id.calendar_id`). When we update the employee's working schedule through the UI on a currently active version, it will also update their associated resource record with the same working schedule. However, if we change the working schedule for a future version, when `_cron_update_current_version_id()` runs and changes the active version, there is no mechanism to update the associated resource with the new working schedule. This change will ensure we keep the working schedules in sync, as if they are not, strange behaviors can occur. One side effect of this problem: When a new version becomes active, and working schedules become de-synced, this can cause the Attendance gannt view to display incorrect unavailable intervals for an employee (this appears as a grayed-out time slot). This is because `_attendance_intervals_batch()` pulls from the working schedule of an employee's associated resource record, rather than the employee record itself. This is what occurred on the linked ticket. [opw-6352770](https://www.odoo.com/odoo/my-tasks/6352770?debug=assets) Forward-Port-Of: odoo/odoo#275430
This update corrects an issue where the customer's address wasn't displayed on the left side of invoices when using specific layouts. Previously, the address was incorrectly positioned on the right. This change ensures invoices consistently display the customer's address in the desired location, improving invoice presentation.
Original PR description
Issue: On an invoice PDF, using a layout with the address on the left. If a contact has a delivery address, but the option "Customer address" is not set, address will be displayed on the right instead of the left. Steps to reproduce: - Create a customer - Add a Delivery address to the customer - Ensure "Customer Address" is not set in the settings - Choose a layout with the address on the left (bubble, wave, ...) - Create an invoice to the customer - print the PDF Current behavior: - Customer address is on the right Expected behavior: - Customer address is on the left Cause: Address is displayed on the right if there is an information bloc . The information bloc was set to an empty div. Therefore, as it is set, address was displayed on the right. opw-6334130 Forward-Port-Of: odoo/odoo#273418
This update resolves an issue where Odoo was incorrectly sending duplicate capture requests to Stripe for EFTPOS payments in Australia. This resulted in payment failures and incomplete orders. The fix ensures that payments processed through EFTPOS are captured only once, improving reliability and order completion rates.
Original PR description
In Australia, Terminal payments using `payment_method_options.card_present.capture_method=manual_preferred` are not always captured later. When a payment is processed on the `eftpos_au` network, Stripe authorizes and captures it in a single step. However, the POS Stripe flow only skipped the extra capture based on the card brand instead of the processed network. As a result, payments such as `brand = visa` and `card_present.network = eftpos_au` were treated as capturable, and Odoo sent a second capture request. Stripe then rejected it with `payment_intent_unexpected_state` because the PaymentIntent had already been captured, leaving the POS order unfinished. This patch skips the extra capture call when the payment was processed on `card_present.network = eftpos_au`. opw-6228977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271609 Forward-Port-Of: odoo/odoo#270293
This update resolves an issue where duplicate stock availability messages were appearing on product pages when using mega menus. The fix ensures that stock messages are correctly cleared and updated, providing a consistent and accurate display of product availability to customers. This improves the user experience and prevents confusion.
Original PR description
Steps to reproduce: - Add an `s_add_to_cart` snippet inside a mega menu - Open a product detail page for a storable product - Change the product variant several times - Stock availability messages…
Steps to reproduce:
- Add an `s_add_to_cart` snippet inside a mega menu
- Open a product detail page for a storable product
- Change the product variant several times
- Stock availability messages keep appending under `availability_messages` instead of replacing the previous one
`_onChangeCombinationStock` removed existing messages with `document.querySelector('.oe_website_sale').querySelectorAll(...)`, but appended the new message with
`this.el.querySelector('div.availability_messages').append(...)`.
`document.querySelector('.oe_website_sale')` only returns the first `.oe_website_sale` element in the document. When a mega menu contains an `s_add_to_cart` snippet, that element appears before the product page container, so the removal step runs on the wrong subtree and never clears the messages on the product page.
Fix by scoping the removal to `this.el`, the current `WebsiteSale` interaction root, so both removal and insertion target the same product page container.
Forward-Port-Of: odoo/odoo#276007
Forward-Port-Of: odoo/odoo#274928This update fixes a problem where background and image shape colors on the website weren't automatically updating when the overall theme color was changed. Now, changes to the theme color presets will correctly reflect in the shape colors used within website snippets and images. This ensures a consistent and visually aligned user experience.
Original PR description
[*]=website 1. Sync background shape color with color preset. Steps to reproduce: 1. Go to the website and enter edit mode. 3. Drop any snippet. 4. Add a background shape. 5. Set the background shape…
[*]=website
1. Sync background shape color with color preset.
Steps to reproduce:
1. Go to the website and enter edit mode.
3. Drop any snippet.
4. Add a background shape.
5. Set the background shape color to "o-color-1".
6. Go to theme tab.
7. Change the value of theme color 1 from theme preset.
Issue:
The background shape color is not updated when the theme color changes.
Reason:
The background shape color is embedded in the URL of the "**background-image**" style attribute. When the theme color value changes, this URL is not updated. Additionally, the URL uses color variables rather than resolved hexadecimal color values as parameters. As a result, even when an updation occurs, the URL itself remains unchanged, preventing the background shape color from being updated.
2. Sync image shape color with color preset.
Steps to reproduce:
1. Go to the website and enter edit mode.
2. Drop any snippet.
4. Click on the image and add a shape.
5. Set the image shape color to "o-color-1".
6. Go to theme tab.
7. Change the value of theme color 1 from theme preset.
Issue:
The image shape color is not updated when the theme color changes.
Reason:
When the theme color value changes, the SVGs are not re-fetched. Additionally, the image "**shapeColors**" dataset stores the hexadecimal value of the theme color instead of the corresponding CSS variable. As a result, there is no way to determine which theme color was selected (for example, whether `o-color-1` or `o-color-2`), since only the hex value is available.
task-5438314
Forward-Port-Of: odoo/odoo#272952
Forward-Port-Of: odoo/odoo#241968This update resolves an issue where Odoo was unnecessarily building internal registries, leading to increased CPU usage on the gevent server. By adapting a key component, this fix prevents over-registry creation and optimizes server performance. This results in a smoother and more responsive Odoo experience.
Original PR description
In [1], the need to build a registry for outgoing messages was removed, but `acquire_cursor` wasn't adapted. As a result, we might end up building more registries than needed, blocking the gevent server CPU. This commit fixes this issue. [1]: https://github.com/odoo/odoo/pull/235746 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where the order tour would intermittently fail to load correctly, particularly when a message was pinned. The fix ensures the tour waits for the pinned message to fully scroll before attempting to navigate, preventing a race condition that caused timeouts.
Original PR description
Jumping to the pinned message highlights it and asynchronously scrolls it into view. On a slow browser that scroll can land right after the tour scrolls to the bottom and pull the thread back up to the pinned message. The load-newer observer callback, which awaits the highlight scroll before re-checking visibility, then finds the bottom sentinel hidden and drops the fetch of the following messages, so the final :count(60) step never matches and times out. Wait for the pinned message to be scrolled into view and for its highlight to clear (its scroll is then finished) before scrolling to the bottom, so the jump scroll no longer competes. https://runbot.odoo.com/odoo/error/941509 Forward-Port-Of: odoo/odoo#275289
This update fixes a discrepancy in the default tax date obligation for Serbian VAT invoices. Previously, the system defaulted to a 'By Issuance Date' setting, which wasn't compliant with Serbian law. Now, it correctly defaults to 'By Delivery Date' as mandated by Article 16 of the Serbian VAT Law, ensuring accurate tax reporting.
Original PR description
According to[ Article 16 of Serbia's VAT Law](https://www.paragraf.rs/propisi/law-on-value-added-tax.html#:~:text=of%20Tax%20Obligation-,Article%2016,-A%20tax%20obligation), the tax obligation arises at the time of delivery of goods/services by default. 'By Issuance Date' only applies to a narrow set of services under Article 16(2a) Before: l10n_rs_tax_date_obligations_code defaulted to '3' (By Issuance Date) After: defaults to '35' (By Delivery Date) Upgrade: odoo/upgrade#10657 task-6348377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273608
This update resolves a bug where changing the website logo option (image to text) didn't consistently hide the logo. The fix ensures the logo is correctly hidden when the 'Company Logo' option is toggled, improving the user experience. This was caused by a configuration issue that has now been corrected.
Original PR description
Steps to reproduce: - Enter in edit mode - Click on the navbar logo - Change "Logo" option from "Image" to "Text" - Toggle "Company Logo" in "Visuals" option - Traceback appears: it should hide the logo This commit awaits `loadConfigKey` so `websiteLogoParams` reads the loaded config; otherwise the button targeted the wrong brand view and collided on the `#o_fake_navbar_brand` xpath. task-6284593 Forward-Port-Of: odoo/odoo#275363
This update corrects an issue where reverting inventory adjustments with packages resulted in negative quantities appearing within those packages. The fix ensures that quantities are accurately restored after reverting, preventing inconsistencies in package inventory levels. This improves data reliability and simplifies inventory management.
Original PR description
Currently when the user reverts an inventory adjustment move line with a package the package contains extra line showing negative quantity of the product. ## Steps to produce: - Install Inventory…
Currently when the user reverts an inventory adjustment move line with a package the package contains extra line showing negative quantity of the product.
## Steps to produce:
- Install Inventory without demo data
- Settings Enable 'Packages'
- Create a product:
- Cheese burger
- On hand > Create a new quant
- Package: 'Burgerbox' and 'On Hand Quantity`: 1 and save
- Set the On Hand quantity to zero and save
- History > Revert the Inventory adjustment line from WH/stock to Inventory adjustment by selecting it and reverting via actions.
- Products > Packages > BurgerBox
## Observed Behaviour:
After reverting an inventory adjustment that set the product's physical quantity to 0, the package contains two lines for the same product with quantities 1 and -1.
This is inconsistent because a package should not contain a product with a negative quantity.
The package should be restored to its original state and contain only the expected positive quantity.
## Root cause:
When the user reverts the move line, `action_revert_inventory` is called. This method creates the revert move and then marks that move as done at [1].
Marking the move as done subsequently marks all related move lines as done at [2]. During this process, the system first unreserves the quantity from the virtual location / inventory adjustment and then removes the quantity from that location (resulting in a -1 quantity move line at that location). This is performed through `_synchronize_quant`, which is responsible for synchronizing the physical inventory with the move line at [3].
The `_synchronize_quant` method uses the move line's `package_id` when updating the corresponding quant at [4]. As a result, `_update_available_quantity` creates a new quant with the following values at [5]:
```
{
'product_id': 1,
'location_id': 14,
'lot_id': stock.lot(),
'package_id': 1,
'owner_id': res.partner(),
'in_date': datetime.datetime(2026, 6, 22, 12, 42, 11),
'quantity': -1.0,
}
```
This creates a quant with a negative quantity that is linked to the package because `package_id` is set on the newly created quant. Consequently, the move line with the negative quantity becomes associated with the package.
[1]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L1016-L1035
[2]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move.py#L1956 [3]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L662-L666
[4]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L678-L687
[5]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_quant.py#L1130-L1143
## Solution:
Remove the source `package_id` when creating revert moves for inventory adjustment locations.
When an inventory adjustment sets a product's quantity to 0, the adjustment is completed without a destination package, meaning the product is effectively removed from the package. Therefore, the corresponding revert move should not retain the package as its source. Keeping the package as the source is inconsistent because package information should not exist on a virtual inventory adjustment location, and the original inventory adjustment removes the product from the package (there is no destination package).
By removing the source `package_id` from the revert move, the system avoids creating negative quants associated with the package during quant synchronization. This also ensures that, after the inventory adjustment is reverted, the quantities of products inside the package are restored correctly and match their state prior to the adjustment.
opw-6285739
Forward-Port-Of: odoo/odoo#274167
Forward-Port-Of: odoo/odoo#271440A recent test failure in our holiday accrual system was caused by an incorrect calculation of holiday allocations in 2027 builds. This update adds a temporary fix to ensure the date remains consistent, preventing the over-allocation of holiday days. This ensures accurate holiday accrual calculations moving forward.
Original PR description
Problem ------------------------ test_department_accrual_allocation was failing due to the allocation being calculated as 26 days instead of 21 in faketime builds set to 2027. This was because the accrual plan was set to accrue 21 days per year and carry over 5 days from the previous year. Since the allocation was created on Jan 1st 2026, all 2027 builds were calculating the allocation to have 5 extra days. Solution ---------------------- Added freeze_time for 2026-03-01 to ensure the date stays the same. runbot-939344 task-6344033 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274154 Forward-Port-Of: odoo/odoo#272728
This update resolves a technical problem within the mass mailing module that was causing errors to appear even when the component was already finished. This fix ensures smoother operation and prevents potential disruptions to email campaigns.
Original PR description
Commit [1] introduced an erroneous `!` operator before status, that would throw loading errors even if the component was already destroyed (those errors should be masked). [1]: https://github.com/odoo/odoo/commit/51c7846f99eb061a1d71ca5d9967f5b01f5551a1 Forward-Port-Of: odoo/odoo#275785
This update resolves an issue where triple-clicking within inline editable content in the HTML editor caused the selection to extend beyond the intended area. The fix ensures that triple-clicks accurately select and highlight the intended editable content, improving the user experience.
Original PR description
Problem: Triple-clicking inside an inline `contenteditable="true"` element causes the selection to extend outside of it. Cause: Inline `contenteditable="true"` elements are not considered when looking for the closest block boundary, allowing the browser selection to expand beyond the editable content. Solution: Treat `contenteditable="true"` elements as block boundaries when searching for the closest block. Steps to reproduce: - Add an inline `contenteditable="true"` element inside an editable area. - Triple-click inside it. - Observe that content outside the `contenteditable` element is also selected. task-6255094 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267487
21 changes
New functionality added to Odoo
This pull request updates the Odoo localization files to include translations for the PayU payment method. This addition supports a new payment option for businesses, expanding Odoo's payment gateway capabilities. It’s a standard I18N update to ensure the system is ready for international use.
Original PR description
Forward-Port-Of: odoo/odoo#275865
Enhancements to existing features
This update improves the performance and functionality of our website by upgrading the Owl library, a key component for handling image galleries and visual elements. Specifically, it addresses a bug that prevented the loss of rendered images and adds support for running the library with Node.js, enhancing flexibility.
Original PR description
- [FIX] runtime: don't lose coalesced renders - [IMP] loadable with nodejs See https://github.com/odoo/owl/commits/owl-2.x/ for more details Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275568
Resolved issues and error corrections
This update resolves an issue where push notifications would stop working after a subscription renewal. The fix ensures the necessary VAPID key information is included during the renewal process, allowing subscriptions to be properly updated and notifications to continue functioning as expected. This improves the reliability of our push notification system.
Original PR description
When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via…
When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via register_devices(). However, the VAPID public key was missing from the request kwargs. The server-side register_devices() always validates the VAPID key first and raises InvalidVapidError when it is absent. This caused the renewed subscription to never be saved in the database, silently breaking push notifications after the first subscription renewal. Fix by extracting the applicationServerKey from the new subscription's options and encoding it as a base64url string (without padding) — matching the existing logic in webclient.js _arrayBufferToBase64(). Description of the issue/feature this PR addresses: Current behavior before PR: Subscriptions don't get renewed causing push notifications to stop eventually. Desired behavior after PR is merged: Subscriptions get renewed successfully. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275411 Forward-Port-Of: odoo/odoo#275217
This update fixes a potential issue in the Point of Sale system where direct access to the IndexedDB could cause data corruption. A new safeguard – a Mutex – has been implemented to manage access and prevent conflicting updates, ensuring data consistency.
Original PR description
In main data service of this PoS indexedDB is called automatically after records are updated.
```js
this.debouncedSynchronizeLocalDataInIndexedDB = debounce(
this.synchronizeLocalDataInIndexedDB.bind(this),
300
);
```
But sometimes, the indexedDB is directly called in the code via `synchronizeLocalDataInIndexedDB` which is not debounced and can lead to race conditions and potential data corruption.
Now the `synchronizeLocalDataInIndexedDB` is inside a Mutex to avoid concurrent access to the indexedDB.
The old method is renamed to `_synchronizeLocalDataInIndexedDB` and is now private.
Forward-Port-Of: odoo/odoo#275892This update resolves a bug where the company logo option in the website navigation wasn't consistently hiding after changing the logo type from image to text. The fix ensures the logo is correctly hidden when the 'Company Logo' option is toggled, improving the user experience and visual consistency of the website.
Original PR description
Steps to reproduce: - Enter in edit mode - Click on the navbar logo - Change "Logo" option from "Image" to "Text" - Toggle "Company Logo" in "Visuals" option - Traceback appears: it should hide the logo This commit awaits `loadConfigKey` so `websiteLogoParams` reads the loaded config; otherwise the button targeted the wrong brand view and collided on the `#o_fake_navbar_brand` xpath. task-6284593 Forward-Port-Of: odoo/odoo#275363
This update resolves an issue where triple-clicking within inline editable text boxes in the HTML editor would incorrectly extend the selection beyond the intended area. The fix ensures that triple-clicks accurately select the intended content, improving the user experience and editor functionality. This change focuses on a minor UI refinement.
Original PR description
Problem: Triple-clicking inside an inline `contenteditable="true"` element causes the selection to extend outside of it. Cause: Inline `contenteditable="true"` elements are not considered when looking for the closest block boundary, allowing the browser selection to expand beyond the editable content. Solution: Treat `contenteditable="true"` elements as block boundaries when searching for the closest block. Steps to reproduce: - Add an inline `contenteditable="true"` element inside an editable area. - Triple-click inside it. - Observe that content outside the `contenteditable` element is also selected. task-6255094 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267487
This update ensures that all invoices sent via Peppol are regularly checked for validity, regardless of whether they are sent in batches or individually. Previously, batch sending didn't automatically verify partner status, requiring manual intervention. This change improves data accuracy and compliance with Peppol regulations.
Original PR description
If you have a partner that wasn't on Peppol. If you only do batch sending, we never re-check its validity. You need to do it by hand, or open explicitely the send&print for an invoice for this customer. We should simply do that check in every case, in batch or in manual sending. task-6296017 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273121
This update ensures that the Pos Cashmatic module's text is properly translated into different languages. By adding the module to the translation files (.weblate.json), the system will now display the correct text for users in various regions. This improves the user experience and accessibility of the Pos Cashmatic functionality.
Original PR description
This commit add the pos_cashmatic module inside the .weblate.json file so that the srings are translated. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275863
This update fixes a visual issue in the API keys kanban view where scope and expiration information for scoped keys were displayed together as a single line. The change now presents these details as separate blocks, improving clarity and readability for users managing API keys. This ensures all key information is easily accessible.
Original PR description
The API keys kanban rendered the "Scope:" and "Expires on:" hints as two adjacent inline <small> elements. For a scoped key both are visible, so they were displayed stuck together, e.g. "Scope: rpcExpires on: ...". Render each hint as a block so they stack on their own lines. Keys without a scope are unaffected since the scope hint stays hidden. Description of the issue/feature this PR addresses: Current behavior before PR: <img width="980" height="414" alt="image" src="https://github.com/user-attachments/assets/6cd8b338-1d2e-4abb-a90b-03218aaef941" /> Desired behavior after PR is merged: <img width="979" height="389" alt="image" src="https://github.com/user-attachments/assets/83ffa680-ffb8-415f-af3f-8e53cb8e8351" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275869
This update resolves an issue where batch payment sequences were incorrectly created when a new company was initially set up. The change ensures sequences are properly associated with the correct company during creation, preventing errors in payment processing. This improves the reliability of batch payments.
Original PR description
Previously, batch payment sequence will be created by simply select to create new company due to having lambda in default. Hence, the created sequence does not have a correct company_id set as company hasn't yet created. Switch to creating sequence in ``create`` function to avoid this issue. Also use ``range_year`` for payment prefix because it was set to use date range. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273852 Forward-Port-Of: odoo/odoo#268689
This change corrects a bug in Odoo's invoice PDF generation. When the 'Hide Composition' feature is enabled on a section, the PDF incorrectly displays a 'Disc.%' column. This fix ensures the column is only shown when actual discounts are present in the invoice lines, improving the accuracy and clarity of invoices.
Original PR description
### Steps to reproduce 1. Create a invoice with a section and add products under it with values 2. Enable **Hide Composition** on the section. 3. Print the invoice PDF. <table> <tr> <td> <img…
### Steps to reproduce
1. Create a invoice with a section and add products under it with values
2. Enable **Hide Composition** on the section.
3. Print the invoice PDF.
<table>
<tr>
<td>
<img width="1278" height="425" alt="image" src="https://github.com/user-attachments/assets/969a222a-5e2f-48e2-962d-fc1cf6440619" />
</td>
</tr>
</table>
### Description
When an invoice contains a section and products in it with values and with **Hide Composition** enabled, the PDF invoice report incorrectly displays the **Disc.%** column header even though no discount values in that section line.
The report currently computes `display_discount` using `o.invoice_line_ids`:
```xml
<t t-set="display_discount" t-value="any(l.discount for l in o.invoice_line_ids)"/>
```
Since `o.invoice_line_ids` still contains the hidden product lines, `display_discount` evaluates to `True`, causing the **Disc.%** column header to be displayed. However, those product lines are replaced by the section line in the report, so no discount values are shown, resulting in an empty column.
### Current behavior
The **Disc.%** column is displayed, but all its cells are empty.
<table>
<tr>
<td>
<img width="808" height="488" alt="image" src="https://github.com/user-attachments/assets/7d9afee6-fef5-49c8-bc4e-b01caa8b43bd" />
</td>
</tr>
</table>
### Expected behavior
The **Disc.%** column should not be displayed when the reported lines do not contain any discounts.
<table>
<tr>
<td>
<img width="798" height="427" alt="image" src="https://github.com/user-attachments/assets/6ffe7985-a7d0-43f5-8d40-41e700ecbed3" />
</td>
</tr>
</table>
### Solution
Compute `lines_to_report` before evaluating `display_discount` and use it instead:
```xml
<t t-set="lines_to_report" t-value="o._get_move_lines_to_report()"/>
<t t-set="display_discount" t-value="any(l.discount for l in lines_to_report)"/>
```
Forward-Port-Of: odoo/odoo#275793This update resolves a critical issue where the purchase catalog feature crashed when viewed on mobile devices. The problem stemmed from a configuration error that prevented the catalog from properly displaying. This fix ensures the catalog functions correctly on all device types, improving user experience.
Original PR description
Currently, th purchase catalog crashes in mobile view. Steps to reproduce: ------------------- * Open purchase order form on desktop * From the devtools put window size to mobile (don't refresh) * Select catalog > Traceback: Cannot find the definition of component "Dropdown" Why the fix: ------------ PurchaseSuggestCatalogSearchPanel extends AccountProductCatalogSearchPanel which also extends AccountProductCatalogSearchPanel. Components were completely overridden and not inherited. opw-6219505 Forward-Port-Of: odoo/odoo#271449
A recent test failure in our holiday accrual system was caused by an incorrect calculation of holiday days in future builds. This PR addressed the issue by adding a temporary 'freeze date' to the system, ensuring that holiday calculations accurately reflect the intended accrual plan. This prevents over-allocation of holiday days.
Original PR description
Problem ------------------------ test_department_accrual_allocation was failing due to the allocation being calculated as 26 days instead of 21 in faketime builds set to 2027. This was because the accrual plan was set to accrue 21 days per year and carry over 5 days from the previous year. Since the allocation was created on Jan 1st 2026, all 2027 builds were calculating the allocation to have 5 extra days. Solution ---------------------- Added freeze_time for 2026-03-01 to ensure the date stays the same. runbot-939344 task-6344033 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274154 Forward-Port-Of: odoo/odoo#272728
This update resolves an intermittent issue where newly opened discuss channels wouldn't display messages correctly. The problem stemmed from how the system canceled rendered fibers, leading to lost updates. This fix ensures that all renders are properly executed, even when fibers are canceled, preventing stale data and ensuring messages are displayed as expected.
Original PR description
Runbot error 940032: a freshly opened discuss channel intermittently renders zero messages for the whole test, with the messages present in the store, `isLoaded` true and no error logged. Two…
Runbot error 940032: a freshly opened discuss channel intermittently renders zero messages for the whole test, with the messages present in the store, `isLoaded` true and no error logged. Two mail-side fixes (9276cf3ab6e4, 65b907f816c4) reduced but did not stop it, because the cause is in OWL's scheduling. When a reactive write notifies a component, OWL first clears all of the component's reactive subscriptions, then invokes its render callback. If the component's parent holds a pending, not yet rendered child fiber for it (the parent is mid-render, e.g. awaiting `onWillUpdateProps`, at least a one-microtask window even with synchronous hooks), the request is coalesced into that pending fiber. If another parent render then cancels that fiber before it could render, `cancelFibers` only set `forceNextRender` for fibers that had already rendered (with a `bdom`): a not yet rendered fiber was dropped without compensation. When the child's props also compare equal to its committed props (a transient prop that changed and reverted compares equal, as committed props are only updated on patch), the cancelling parent pass skips the child entirely. The coalesced render is lost, and since the subscriptions were already cleared, the component becomes deaf to every subsequent store change: stale DOM forever, no error, until an unrelated explicit render heals it. In the discuss case the lost render is the one that would have displayed the freshly loaded messages, and the parent double-render around the load completion comes from ordinary transient prop churn while the channel opens. Force the next render of a mounted node whose not yet rendered fiber is cancelled, as OWL 3 already does. This vendors the fix made on the owl 2.x branch ahead of its next release. The regression test reproduces the exact runbot failure deterministically by gating `onWillUpdateProps` to widen the natural microtask window. https://runbot.odoo.com/odoo/error/940032
This update resolves a crash in the HTML editor when users type URL-like tokens (e.g., auto-linked URLs) in fields like contact notes. The fix ensures the editor correctly handles selections in Safari, preventing the 'IndexSizeError' and allowing users to continue typing without interruption. This improves the user experience for a common task.
Original PR description
Typing in an HTML field (e.g. a contact's Internal Notes) and validating a URL-like token with Enter or Space can crash the editor with "IndexSizeError: The index is not in the allowed range",…
Typing in an HTML field (e.g. a contact's Internal Notes) and validating
a URL-like token with Enter or Space can crash the editor with
"IndexSizeError: The index is not in the allowed range", leaving the
user unable to continue typing. It happens on Safari (not Chromium).
The trigger is a URL-like token that the editor auto-converts into a
link. The splitText calls in prepareConvertToLink, run during
beforeinput, leave Safari's native selection anchored on an empty text
node with an out-of-range offset. Anything reading the selection
afterwards then works from a broken position: on Enter, splitBlock
reads it and makeActiveSelection ends up throwing in Range.setStart;
on Space, the browser inserts the character in the wrong node and the
selection is corrupted the same way.
```
UncaughtClientError > IndexSizeError
Uncaught Javascript Error > The index is not in the allowed range.
setStart@[native code]
createEditorSelection@.../web.assets_web.min.js:12239:15
getSelectionData@.../web.assets_web.min.js:12242:145
updateActiveSelection@.../web.assets_web.min.js:12230:92
@.../web.assets_web.min.js:12218:873
handler@.../web.assets_web.min.js:14366:121
```
Steps to reproduce:
1. Use Safari (Chromium-based browsers work fine)
2. Open any record with an HTML field (e.g. Contacts -> a contact ->
Internal Notes).
3. Type a URL-like token such as KF.16D2.0204.CG (.CG is a valid TLD,
so the editor auto-links it). Do not paste it.
4. Place the caret at the end of that token and press Enter or Space.
5. IndexSizeError is raised and the editor stops accepting input.
Fix it at the source: re-anchor the selection right after the splits in
prepareConvertToLink, so every consumer sees a valid caret position.
Since moving the selection during beforeinput makes WebKit cancel the
pending text insertion, the Space case now prevents the default and
performs the conversion, the space insertion and the caret placement
itself, in two history steps so that undo still reverts the link
conversion while keeping the typed space.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#275587
Forward-Port-Of: odoo/odoo#270910This update fixes an issue where images weren't displaying correctly in Outlook email clients. The changes backport a solution from a previous development branch to ensure consistent image rendering across all email platforms, improving the user experience for customers receiving emails with attachments.
Original PR description
Backport the changes from `b9370ea6b70ca3020c73a6940d70ff0cf954f69f` into `mail/convert_inline` to ensure Outlook-compatible image rendering. opw-3776054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269628 Forward-Port-Of: odoo/odoo#269436
This update ensures that the Point of Sale system always uses the fiscal position that is both allowed and best suited for a customer, preventing errors where an unauthorized position was being selected. Previously, the system prioritized fiscal positions based on order, leading to incorrect selections. This fix improves data accuracy and reliability during sales transactions.
Original PR description
**Steps to reproduce:** - Create a fiscal position T1, with detect automatically - Create another one T2, without the detect automatically - When looking at the fiscal positions list, make sure T1 is…
**Steps to reproduce:** - Create a fiscal position T1, with detect automatically - Create another one T2, without the detect automatically - When looking at the fiscal positions list, make sure T1 is on top, followed by T2 - Go to the PoS settings, check flexible taxes - Put T2 as default and in allowed, don't put T1 in allowed - Go to the PoS, chose a customer - The fiscal position is T1 even though it's not allowed **Why the fix:** Currently, the fiscal position is chosen like this in order: - A FP specified on the customer's profile - A FP detected with the detect automatically setting - The default FP from the PoS settings When we have a tie, it's the first one in the fiscal positions list that is chosen. Before this commit, we did not check that the fiscal position was allowed to be used in the PoS, so we just fetched whatever fiscal position fit the best for a given customer and didn't check if we could actually use it. We now make sure that the fiscal position we try to use is allowed in the current PoS, and if it's not we fall back to the default one. opw-6032031 Forward-Port-Of: odoo/odoo#271343
This update fixes an issue where expense accounts weren't being correctly applied during Point of Sale transactions. Now, the system prioritizes mapping expense accounts through the fiscal position, ensuring accurate financial reporting for sales without invoices. This improves the reliability of financial data.
Original PR description
**Steps to reproduce:** - Make a product with a category - In the category, make the inventory valuation to automated - Set the income and expense account - Set a cost for the product - Make a fiscal…
**Steps to reproduce:** - Make a product with a category - In the category, make the inventory valuation to automated - Set the income and expense account - Set a cost for the product - Make a fiscal position and set it as default for the PoS - In the Account Mapping tab, map the income and expense to two other accounts - Go to the PoS - Make a sale for that product, without invoice - Close the session and in the backend check the session - Check the journal entries - The income account has been mapped to the fiscal position's - The outcome account stayed the same as in the category's **Why the fix:** When we invoice an order, the income and expense accounts are immediately updated, in a different place than if it has not been invoiced. At the session's closure, we update the accounts for every order that hasn't been invoiced. In this flow, the account mapping defined on the fiscal position was not applied, so we took the one defined on the product's category. The income account was already mapped as we need to do it earlier than the session closure, so it had already been set as the right one before our flow. For the expense account, we only need it at this specific time, so we can map it as the session's closure. We now map the account depending on the fiscal position if we are able to find one, otherwise, we use the category's default as we did before. opw-6171677 Forward-Port-Of: odoo/odoo#275114 Forward-Port-Of: odoo/odoo#266700
This update fixes a glitch where customers could repeatedly top up their loyalty program balances using only top-up products, creating an 'infinite money' scenario. The change ensures that an eWallet payment won't process if the order consists solely of top-up products, preventing over-discounts and maintaining accurate balance tracking. This improves the stability and reliability of our loyalty program features.
Original PR description
### Steps to reproduce: - Download 'Sales' application - From 'Configuration' > 'Settings', enable 'Promotions, Loyalty & Gift Card' - From 'Products' > 'Gift cards & eWallet', Configure an eWallet…
### Steps to reproduce:
- Download 'Sales' application
- From 'Configuration' > 'Settings', enable 'Promotions, Loyalty & Gift Card'
- From 'Products' > 'Gift cards & eWallet', Configure an eWallet program with a top-up product
- Have a customer with an existing eWallet balance
- Create a new sale order for that customer and add the eWallet top-up product
- Pay the order using the customer's eWallet
> The order gets discounted by the eWallet, effectively allowing the user to top up their balance
using the balance itself (infinite money glitch).
### Cause of Issue:
When computing the discountable amount for payment programs (like eWallets and gift cards), `_discountable_order` includes the total order amount. However, it did not exclude the program's own top-up products (`trigger_product_ids`) from the discountable lines.
### Fix:
If an order consists solely of top-up products, attempting to apply the eWallet now correctly raises a `UserError` ("There is nothing to discount").
opw-6341410
Forward-Port-Of: odoo/odoo#273419This update resolves flaky tests related to channel subscriptions, ensuring accurate tracking of member status. The fix addresses a fundamental bug where channel membership changes weren't reliably triggering updates, leading to incorrect behavior. By adding a third state, the system now correctly identifies and responds to membership changes relative to the bus start time.
Original PR description
The "bus subscription is refreshed when channel is joined/left" tests were flaky: - `mockDate` needs 2 digit date/time parts. The format used here didn't always produce them, so it silently fell back…
The "bus subscription is refreshed when channel is joined/left" tests were flaky: - `mockDate` needs 2 digit date/time parts. The format used here didn't always produce them, so it silently fell back to a past date. That was enough to make the "left" test pass even without actually leaving. - The "left" test never actually left the channel: a confirm dialog blocked it. - The "join" test never actually joined the channel. - The tests expected `runAllTimers` to guarantee that every initial subscription was done, but thats not the case, making the number of `subscribe` calls non-deterministic (e.g. flushing calls to `bus_service.add` but not ensuring the worker received them through its message port, and triggered the debounced `updateChannels`). Fixing the tests exposed a real bug: `memberBusSubscription` is meant to trigger a refresh whenever membership changes relative to the bus start time. As a boolean, "member, no refresh needed" and "not a member" are indistinguishable (both `false`), so leaving a channel joined before the bus started never changed the value and never triggered a refresh. This PR add a third state so membership and non-membership stay distinguishable regardless of when the bus started. runbot-941462 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275938
This update resolves a problem where duplicate stock availability messages were appearing on product pages when using mega menus. The fix ensures that messages are correctly cleared and updated, providing accurate stock information to users. This improves the overall shopping experience and prevents misleading stock levels.
Original PR description
Steps to reproduce: - Add an `s_add_to_cart` snippet inside a mega menu - Open a product detail page for a storable product - Change the product variant several times - Stock availability messages…
Steps to reproduce:
- Add an `s_add_to_cart` snippet inside a mega menu
- Open a product detail page for a storable product
- Change the product variant several times
- Stock availability messages keep appending under `availability_messages` instead of replacing the previous one
`_onChangeCombinationStock` removed existing messages with `document.querySelector('.oe_website_sale').querySelectorAll(...)`, but appended the new message with
`this.el.querySelector('div.availability_messages').append(...)`.
`document.querySelector('.oe_website_sale')` only returns the first `.oe_website_sale` element in the document. When a mega menu contains an `s_add_to_cart` snippet, that element appears before the product page container, so the removal step runs on the wrong subtree and never clears the messages on the product page.
Fix by scoping the removal to `this.el`, the current `WebsiteSale` interaction root, so both removal and insertion target the same product page container.
Forward-Port-Of: odoo/odoo#2749285 changes
Enhancements to existing features
This update enhances the product configurator within Point of Sale. Now, when a barcode scan matches a product variant, the pre-selected options (like color) are automatically filled in, mirroring the experience when searching for a product by barcode. This simplifies the process for sales staff and improves accuracy.
Original PR description
When a barcode scan matches a specific product variant, the product configurator now behaves the same as when the user searches by barcode: - The `always`-mode attribute (e.g. Color) is preselected from the matched variant instead of being hidden or left blank. - The `no_variant`-mode attributes (e.g. Size) are shown for user input. opw-6220883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267038 Forward-Port-Of: odoo/odoo#265189
Resolved issues and error corrections
This update ensures that the default placeholder for the Klipy search feature displays "Search KLIPY", as required by Klipy's attribution guidelines. This change maintains compliance with Klipy's documentation and improves the user experience for Klipy users within Odoo. It was a necessary fix to align with external partner requirements.
Original PR description
Klipy requires attribution with "Search KLIPY" as the default placeholder [1]. This commit complies these guidelines. [1]: https://docs.klipy.com/attribution Forward-Port-Of: odoo/odoo#275894 Forward-Port-Of: odoo/odoo#275677
This update fixes a potential issue where loading certificates could cause the Odoo system to crash with an error message. The change ensures that loading errors are handled gracefully, preventing unexpected downtime and improving the overall stability of the certificate management process. This enhances the reliability of our secure connections.
Original PR description
Loading a certificate could raise an unhandled exception instead of failing gracefully. Clearing the content, uploading a bundle with a corrupted certificate block, or handling certificates with unsupported signature algorithms or malformed extensions all could end up in a traceback. Guard those paths to ensure loading errors are handled. opw-6370529 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275325
This update corrects a display issue where debit notes were consistently shown in English, regardless of the user's selected language. The fix prevents overriding core Odoo translation settings, ensuring that debit note titles are now correctly translated based on the user's language preference. This improves the user experience for international customers.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Switch to another language 3. Go to an invoice (or create a new one) 4. Create a debit note for that invoice and print it or…
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Switch to another language 3. Go to an invoice (or create a new one) 4. Create a debit note for that invoice and print it or send it 5. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Cause of the issue: This PR wants to fix c81be50733fcc9db5a3c903e7a571ce87c8f12bc. In that commit, the view inheritance used position="replace" to redefine the entire document title block. By doing so, standard strings like "Invoice" and "Invoice Date" were hardcoded directly into the account_debit_note view. Since these base terms are not exported to the translation files (.pot/.po) of the account_debit_note module to prevent duplication, Odoo fails to find their translations locally. Consequently, it ignores the existing translations from the base account module and falls back to displaying the terms in English. ### Reason to introduce the fix: To restore the broken translations, we must avoid overriding the base XML nodes of the account module. Instead of replacing the entire block, this fix applies a minimal diff. This approach leaves the original base strings untouched, allowing Odoo's translation engine to successfully retrieve and apply the correct translations from the core account module. opw-6341939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where duplicating a purchase receipt incorrectly inflated the received quantity on the original purchase order. The change ensures that only the actual incoming delivery quantity is counted, resolving a discrepancy in how the system calculates received items. This improves the accuracy of purchase order tracking.
Original PR description
On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po. Steps to reproduce: ------------------- *…
On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po. Steps to reproduce: ------------------- * Create a PO and confirm it * Open the receipt, validate and duplicate it * Go on the duplicated receipt and change its Operation Type * Confirm the duplicated receipt. -> the Received Qty on the Po counted the duplicated and modified transfer. Observation: ------------- When we duplicate a stock.picking, we will call ```copy``` and copy all its ```move_ids``` (stock.move), and in stock.move we will copy the ```purchase_line_id``` : https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5868 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5881-L5892 https://github.com/odoo/odoo/blob/3e6d93bef49bb2718e8aa1756f95c2a6117c8d55/addons/purchase_stock/models/stock_move.py#L13-L15 the ```purchase_line_id``` will keep the link with the pol. The fields are copied since they have ```copy=True``` https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/addons/stock/models/stock_picking.py#L614 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/fields.py#L304 Because new stock moves are linked directly to the Purchase Order Line (POL), the qty_received calculation aggregates all associated move quantities. https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L73-L76 opw-6088239 Forward-Port-Of: odoo/odoo#272172 Forward-Port-Of: odoo/odoo#259570
27 changes
Enhancements to existing features
Map popovers can now use the same flexible card-style layout system used elsewhere in Odoo, making their content easier to structure and customize. Existing map popovers continue to work for now, while related map view extensions and tests were updated to support the new approach.
Original PR description
*: web_studio,stock_enterprise
This PR if a followup of [1] and introduces the ability to use the card
API to declare map popover. The map archs now expects a
```xml
<popover>
<templates>
</templates>
</popover>
```
node which can declare `popover-header`, `popover-body` and
`popover-footer` templates. Those templates follow the same API as
cards (kanban). Moreover, a `card_id` attribute can be set on the
`popover` node to declare the card view to use as popover body.
Note: the previous API keeps working (temporarily).
This PR also adapts the various JS extensions of the map view.
[1]: https://github.com/odoo/odoo/pull/260098
task-6310630Payment token records for SEPA Direct Debit now show the linked mandate directly on the form. This makes it easier for staff to verify the authorization behind a saved payment method without navigating elsewhere.
Original PR description
Add sdd_mandate_id on the payment token form. See https://github.com/odoo/odoo/pull/268220 task-6251341
An unused repair-related view and action were removed from the planning field service repair module. This cleans up the application internals and reduces maintenance overhead without changing the visible user experience.
Original PR description
Currently, action_open_reference_no_repair is not called anywhere, so the view remains unused. Therefore, this commit removes the unused view.
Payslip lines now show an information tooltip explaining how each amount was calculated, helping payroll users answer calculation questions directly in the payslip. Payroll teams can configure explanation text on salary rules, with an initial Belgian payroll example included.
Original PR description
Each salary line is the result of a computation. To help the end user understand how the amounts are derived and lower the number of "how is this computed?" questions, an info icon is now displayed on hover on the backend of the payslip line. This commit introduces the framework to support this: - Adds an `explanation_template` text field on the salary rule to configure the logic. - Safely evaluates the template during the payslip computation. - Introduces an `explanation_tooltip` widget to display the translated result on hover in the UI. - Implements a first test rule as an example in the Belgian payroll. Task Id: 6268188
Helpdesk teams can now create invoices for several solved tickets at once from the action menu. This reduces manual work and speeds up billing for completed support services.
Original PR description
Before this PR : - No available method to create invoices for multiple solved tickets in batch. After this PR: - A 'Create Invoices' action is added in the action menu to invoice multiple tickets in batch. Task id: 4243781
Uzbekistan financial reports now include Russian translations alongside Uzbek. This helps companies operating in Uzbekistan serve Russian-speaking users and improves adoption in the local market.
Original PR description
Uzbekistan's business environment requires Russian in addition to the official Uzbek language to ensure adoption. While localizations typically activate only statutory languages, Central Asian market realities justify this exception. task-6229114 -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#122901 Forward-Port-Of: odoo/enterprise#120250
This update adds support for temporary economic unemployment leave handling for Belgian worker employees. It helps payroll teams apply the correct leave codes for workers versus other employee types, improving payroll compliance and reducing manual correction risks.
Original PR description
[IMP] l10n_be: economic unemployement for workers
adding new work entry type Temporary economic unemployment for employee
. add a constraint to hr.leave that if employee is worker then he should use LEAVE6665 else LEAVE13720
task - 6358912Product availability checks for rentals and subscriptions are now handled through one shared purchase rule instead of several separate checks. This makes product filtering and add-to-cart behavior more consistent and easier to maintain, reducing the risk of mismatched storefront behavior.
Original PR description
Replace the ad-hoc _website_show_quick_add / _is_add_to_cart_allowed / _can_be_added_to_current_cart / _website_can_be_added overrides with a single override of _is_purchasable() in both modules, removing website_sale_subscription/models/product_product.py entirely. Community PR: - https://github.com/odoo/odoo/pull/252296 task-5491803
Payroll users can now access Import and Export options directly from the time off Gantt view in the pay run time step. This removes the need to switch to list or kanban views when moving time off records in or out of Odoo.
Original PR description
The pay run "time" step shows time off (hr.leave) records in a gantt, list and kanban view. The standard "Import" and "Export" cog menu entries only show up on list/kanban views, so they were missing from the gantt, even though they are available on the very same records in the list. Surface both entries on the hr.leave gantt as well: - the base "Import" and "Export" cog items are reused, scoped to the hr.leave gantt via their isDisplayed; - since gantt controllers do not wire the direct xlsx export (only list and kanban do), install useExportRecords on the gantt controller, backed by a minimal list-like root built from the gantt search params so no state has to be added to the model. task-6348558
HR teams can now set Christmas bonus day counts for each employee version instead of using one company-wide value. This better supports Mexican payroll cases where bonus entitlements differ by agreement, seniority, or bargaining terms, and ensures related payroll calculations use the employee-specific value.
Original PR description
Previously, the Christmas bonus days parameter (l10n_mx_christmas_bonus) was configured at the company settings level, imposing a uniform value across all employees. In Mexico, Christmas bonus entitlements often vary based on individual negotiations, seniority, or collective bargaining agreements. Moving this parameter to the employee version level allows HR managers to specify custom bonus day counts per individual **what:** - Added the l10n_mx_christmas_bonus float field to the employee versioning model with a default value of 15.0. - Updated the XML view to expose the field within the version context of the employee form. - Refactored the calculation logic inside the BASIC (Basic Christmas Bonus) and PROVISIONS_CHRISTMAS_BONUS salary rules to retrieve the bonus days dynamically from the active employee version. - Updated the l10n_mx_integration_factor processing logic to respect the version-specific value. task-6371803
Belgian payroll now recognizes three additional leave types for salary processing, declarations, and payslip workflows. This helps ensure payroll treatment and reporting align with Belgian leave rules, including correct handling of reorganization measures for eligible leave types.
Original PR description
- Add LEAVE14704, LEAVE14708, and LEAVE14713 to the relevant salary structures, DMFA calculations, and payslip workflows. - Map salary categories and DMFA configurations for the new leaves following the existing MEDIC01 baseline. - Configure LEAVE14704 (palliative care) and LEAVE14708 (informal carer) to open reorganization measures, while explicitly excluding LEAVE14713 (time credit not equated) from triggering them. Task: 6361609
VoIP softphone contact lists now show more relevant people first when searching, such as internal colleagues during transfers and recently called contacts in other searches. The update also reduces confusing gaps, scrolling issues, and misleading “more results” counts, making it easier to find the right contact quickly.
Original PR description
Review the order contacts are listed in the softphone, trying to show the most meaningful ones first, and fix a few issues along the way. [FIX] voip: mitigate loading/scrolling softphone bugs The…
Review the order contacts are listed in the softphone, trying to show the most meaningful ones first, and fix a few issues along the way.
[FIX] voip: mitigate loading/scrolling softphone bugs
The VoIP softphone basically loads contact data in two cases: when
browsing/searching for contacts and when scrolling a contact list to
browse more. The way it works is currently performant rpc-wise... but
very wrong: each time a contact is loaded, it ends up in the client
Store and when the user later browses/searches for contacts, that Store
is used before allowing to "browse more" by scrolling.
This leads to many bug variants, like this one:
- Have a "long" (e.g. 50) list of contacts
- Search for the contact name "Z", the last one
- You find maybe 10, likely at the end, then remove the search
=> You now see 13+X contacts, 13 first of the DB alphabetically then X
"Z" loaded previously. It's already a visual bug: you see a lot of
missing contacts between the 13 first and "Z".
- Scroll
=> Contacts appears only once you reach the last "Z" but they might
appear at the very top (e.g. a "B" not yet loaded).
Now another bug:
- Have a "long" list of contacts, including 15 with last name "Smith"
- Open the contacts list (e.g. transfer view), type "Smith"
=> You see 13 Smith, good
- Try to scroll to load the last 2
=> You probably can't... because you already loaded more than 15
contacts just by opening the contact list
... there are many variants of this bug. Basically, with or without
search, you see a list of contacts with "gaps" and you can't expect to
be able to find all contacts (matching a search or not) by scrolling.
The only certainty you have is that if you enter the *exact* name of a
contact, you will find it (if there are no more than 13 with the same
exact full name).
This would require a deeper VoIP changes to fix properly keeping good
perfs, which is not the focus at the moment. This commit however tries
to mitigate the issue when scrolling a list with a new search.
Note that the following commits kinda worsen this mitigated issue, but not by much.
[IMP] voip: show internal users first in transfer view while searching
The softphone displays searched contacts ordered alphabetically. This
commit now also first display internal users of the database, only when
a search is performed, only while searching for a contact to which a
call has to be transferred. Indeed, when transferring, it is likely you
want to transfer to one of your colleague, and after a 2-3 letters
search, it should be enough for your colleague to be nearly alone at the
top, while searching for "James" could lead to 100 "James" regrouping
all the contacts your company is dealing with.
[IMP] voip: show 3 most recently called contacts first when searching
The parent commit introduced transfer search sorting that puts internal
users first, as those are the most likely people you want to transfer a
call to.
With a similar idea in mind, this commit puts the 3 user's most recently
called matching contacts first in the other contact search contexts.
[IMP] voip: review keypad suggestion "more" button label
The keypad fetches 30 contacts once a search is performed. It then
shows only one and shows a "more" button indicating the remaining
amount. In case 30 contacts were fetched (matching the search), it
showed "29 others"... although there might be more unloaded in the
database.
We now show 1, 2, 3, ..., 30 "others" if that is the exact amount in
the database. Otherwise we show the amount we already have loaded client
side, minus 1, with a "+". E.g. if 75 were loaded previously, matching
the search, we show 1 suggestion + "73+ others" as button, knowing there
could be more than 75.
To achieve this, we load 32 contacts at the first search, instead of 30:
1 suggestion + a potential exact "30 others" + 1 to show "30+" if needed
[IMP] voip: improve consistency of softphone interactions
The softphone mostly consists of "tab entries" which can be opened or
scrolled through. This commit makes it tab entries are closed and the
scroll reset consistently.
For example: if you search for a contact, open its entry, call it then
come back later to the contact entry, it will be closed instead of still
opened. The scroll might also have jumped to the contact entry that was
previously opened... now each search properly shows the tab entries from
the start.
task-6326451This update improves the payroll user experience by refining payroll batch handling and Belgian payroll work entry type views. These changes help HR teams work more smoothly and reduce friction in day-to-day payroll administration.
Original PR description
task-id: 6360832
The Payroll employee type screens were adjusted to make them easier to use and more consistent, including related Belgian payroll views. This helps HR and payroll teams manage employee classifications with less friction and clearer navigation.
Original PR description
task-6357922
Obox device forms now include a Test button so users can quickly verify printers, scales, and cameras from the device page. Printer testing now lets users choose the print format, making setup and troubleshooting easier.
Original PR description
This commit adds a Test button to the Obox device form, similar to the IoT device form. It is supported for all three device types (printer, scale, camera). For printers, the user must select which type of test print to perform (PDF, receipt, ZPL). task-6332378
Resolved issues and error corrections
Users can no longer save an IoT report printer configuration without choosing an actual printer device. This prevents failed print jobs later by catching incomplete setup during configuration.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/273723 Before this commit, you could configure an IoT report printer but not select any IoT printer device, which would cause printing to fail later on. After this commit, the field is required so the user must select a printer device before saving. task-6333695 Forward-Port-Of: odoo/enterprise#122652
This fixes an internal Swiss payroll test so it still checks that employees without a private country trigger the expected warning. The change keeps automated payroll quality checks reliable after a related default-country behavior change.
Original PR description
The warnings test expects a warning to be generated on the payslip because the employee is missing a private country. However, the referenced change introduced a default value for the private country based on the active company. Because the field is no longer blank upon employee creation, the payroll engine no longer flags it as missing, causing the test to fail. See odoo/odoo#275579 task-6361855
Belgian payroll now uses the official daily Partena amount for private car reimbursements in CP 200 and CP 302 instead of estimating it from a monthly train subscription. This helps produce more accurate payslips for affected employees while preserving the previous calculation for other sectors or older periods.
Original PR description
Previously, the private car reimbursement for CP 200 and CP 302 was calculated by dividing a monthly train subscription price into a daily rate. This commit changes the logic to take the exact daily amount from Partena instead of converting a monthly price, while keeping the old train method for other sectors or past dates. Task-6357956
Users who are not linked to an employee can now create expenses from documents, as long as they have permission to create expenses for another employee. This removes an unnecessary blocker while keeping existing access controls in place.
Original PR description
Removes the constraint saying a user has to be linked to an employee to create an expense from a document. In this case, the user still needs the rights to create an expense for another employee. task-6237021 Forward-Port-Of: odoo/enterprise#123635 Forward-Port-Of: odoo/enterprise#118955
This fix updates tax-related modules so calculated values refresh correctly when draft or in-memory records are created. It helps prevent stale or missing external tax information in workflows that rely on Avatax or external tax integrations.
Original PR description
Now field dependencies of abstract models are resolved on the abstract model itself in order to trigger the recomputation of computed fields on new() records of abstract models. These changes are safe to apply independently of the ORM change, since dependencies that do exist on the concrete models are unaffected. Community PR: https://github.com/odoo/odoo/pull/275788.
This fixes an inconsistency in how the Hong Kong payroll rental field is configured between employee records and version records. The change helps prevent related automated test failures and improves reliability without changing day-to-day payroll workflows.
Original PR description
The readonly value inconsistency between l10n_hk_rental_id field in the employee's model and the one in the version's model was provoking some tests to fail. Related runbot error: https://runbot.odoo.com/odoo/error/241956 task-6306032 Forward-Port-Of: odoo/enterprise#120673
Belgian payroll structural deductions now use the correct contribution rate based on whether the person is classified as a worker or employee. This prevents deductions from being calculated with a zero rate when the default lookup does not find the right payroll contribution type.
Original PR description
For structural deduction computation, getting onns rates via `_get_onss_rates()` sometimes default to zero if no rate was found using the default contribution type. Now passing the appropriate contribution type depending on the version status (worker/employee). Task: 6313510
Fixed an issue where opening a Measure step in Shop Floor could fail because required dialog information was not passed correctly. This ensures operators can record measurements without interruption after the underlying component behavior changed.
Original PR description
Steps to reproduce: - Open Shop Floor - Create a Measure step - Click on the Measure Button - Encounter the error Upon further observation, it was noticed that the properties were not passed correctly to the MrpMeasureDialog component. This happened due to incorrect property definition in OWL 3, while with OWL 2 it was correct. Property definition was changed to comply with OWL 3. task-6345156 Forward-Port-Of: odoo/enterprise#122269
POS users can now access the Kitchen Display directly from the main dashboard without encountering an access error. This removes an unnecessary blocker and makes the dashboard entry point consistent with access from within the POS app.
Original PR description
**Description of the issue/feature this PR addresses:** When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to…
**Description of the issue/feature this PR addresses:**
When a POS user attempts to open the Kitchen Display app from the main dashboard, they are blocked by an Access Error, despite being able to access the interface from within the POS app's sub-menu.
This occurs because the dashboard menu triggers a server action (`action_pos_preparation_display_kitchen_display`) to route the user. When a server action has no explicitly defined `group_ids`, Odoo's `_can_execute_action_on_records` method falls back to requiring `write` access on the underlying model (`pos.prep.display`) to execute the code. Since standard POS users do not have 'write' access to this model, the execution engine blocks the routing attempt.
This commit resolves the issue by explicitly appending the POS User group to the server action's `group_ids`.
opw-6305014
**Steps to reproduce:**
- As Mitchell Admin:
- Settings > Users & Companies > Users > Marc Demo > Access Rights > Sales > set POS to User
- As Marc Demo:
- Attempt to access Kitchen Display app > observe Access Error
- POS > Orders > Preparation Display > observe no error
**Current behavior before PR:**
- POS Users receive an Access Error when attempting to access the Kitchen Display app from the main dashboard
**Desired behavior after PR is merged:**
- No Access Error when POS Users access the Kitchen Display app
Forward-Port-Of: odoo/enterprise#122531
Forward-Port-Of: odoo/enterprise#121419Mexican payroll documents now correctly show holiday bonuses and their related tax in payslips and CFDI XML files. This prevents mismatches between payroll calculations and reported totals, improving accuracy for employees and compliance reporting.
Original PR description
Currently, the holiday bonus exemption is calculated correctly internally, but it is not displayed on the payslip PDF or the CFDI (XML) file because it lacks dedicated concepts. This causes amount…
Currently, the holiday bonus exemption is calculated correctly internally, but it is not displayed on the payslip PDF or the CFDI (XML) file because it lacks dedicated concepts. This causes amount discrepancies between the calculation and the totals reported. Error: For an employee with a 50,000 MXN monthly salary (pays 9,107.82 MXN ISR and 1,462.78 MXN IMSS). On their first anniversary, they receive a 5,000 MXN holiday bonus and pay 762.13 MXN ISR for it. The PDF and XML files show a perception total of 50,000 MXN and a deduction total of 10,570.60 MXN, completely ignoring the holiday bonus and its specific tax. In the PDF, the calculation is correct: 50,000.00 + 5,000.00 - 10,570.60 - 762.13 = 43,667.27 MXN. However, the XML net total reports: 50,000.00 - 10,570.60 = 39,429.40 MXN (ignoring the bonus amounts). Solution: Add a new salary rule and perception concept to properly separate and display the taxable and exempted amounts on the PDF and the CFDI. Add a new deduction concept to report the holiday bonus ISR. This ensures complete synchronization across the payslip, PDF, and XML. target: master task-6255412
The Analytic Items grid now keeps the same sectioned layout when users apply grouping options. This makes the view more predictable and easier to read, avoiding a confusing switch between flat and hierarchical rows.
Original PR description
Prior to this commit, the Analytic Items grid view exhibited inconsistent layout behavior. Applying a single custom group-by resulted in flat rows, while applying two or more group-bys (or using the default XML) triggered a sectioned hierarchy. This commit ensures a consistent UX by intercepting the grid metadata in `AnalyticLineGridModel.loadData`. If no section field is defined by the base model, the first grouping is now forcefully promoted to `sectionField`. Task-6321646
Code cleanup and technical improvements
This update adjusts how the Gantt view scrolls to the right date so it remains reliable with the newer interface framework. Users should see the same behavior, with reduced risk of layout or scrolling issues during rendering, resizing, or range changes.
Original PR description
`useLayoutEffect` is deprecated in OWL3. The remaining call (initial-scroll / focus-date scrolling) becomes `onMounted`+`onPatched`: a timing constraint, not a shim, since `focusDate` reads live post-patch DOM (`cellContainerRef.el.clientWidth`) before writing `scrollLeft`. A reactive `useEffect` fires before the DOM patch and would measure stale layout. Test coverage — these failed with the effect commented out and now pass: - @web_gantt/gantt_view_basics/ungrouped gantt rendering - @web_gantt/gantt_view_behavioral/resize a pill - @web_gantt/gantt_view_concurrency/concurrent range switches see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2624590/build/116553816
4 changes
Resolved issues and error corrections
This update resolves two issues impacting the web push subscription process. Specifically, it corrects a logic error in how device ownership is checked and ensures the correct key is used when sending subscription information to the server, preventing duplicate device creation. This enhances the overall reliability of the web push functionality.
Original PR description
This fixes two bugs in the web push subscription flow:
- register_devices() compared partner records with 'is not' instead of '!='. Records loaded via sudo() live in a different environment than self.env.user, so 'is not' was always True and the ownership guard never behaved as intended. Use '!=', which compares record identity by model and id as Odoo's ORM intends.
- webclient.js sent the previous subscription endpoint under the snake_case key 'previous_endpoint', while the server reads it as 'previousEndpoint' (kw.get('previousEndpoint', endpoint)). The mismatch meant the lookup always fell back to the new endpoint, so a refreshed subscription created a duplicate device instead of updating the existing one. Send the camelCase key to match the server.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update ensures notification sounds play correctly on touch devices (smartphones, tablets, and laptops with touchscreens) by utilizing the device's native push notification system instead of the browser's audio channel. This resolves an issue where notifications were unexpectedly playing through the device's speaker even when the device was muted.
Original PR description
On touch devices (smartphones, tablets), the in-browser notification sound plays through the media audio channel, which is not affected by the device's silent mode. This causes unexpected sound playback when the device is set to silent. Suppress _playSound() on devices with maxTouchPoints > 1 (touch/mobile). Push notifications handle alerts on mobile and properly respect the device's silent mode. The side effect is that also laptops with touch screen are affected and need to use web push notifications in order to get notification sounds played. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue where specific error messages related to zero percentages in account reconciliation were inconsistent. The change aligns these messages with the correct amount type being validated, providing clearer guidance to users when entering zero values. This improves the user experience and helps ensure accurate reconciliation processes.
Original PR description
In _validate_amount(), setting a "Percentage of balance" line to 0 raises "Statement line percentage can't be 0", and setting a "Percentage of statement line" to 0 raises "Balance percentage can't be 0". Align each error message with the amount type being validated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269393
This update resolves an issue where dropdown menus remained visible on the POS screensaver. The fix ensures that all active overlays, like menus, are properly closed when the screensaver is activated, improving the user experience and preventing visual clutter. This enhances the overall usability of the Point of Sale interface.
Original PR description
Currently, overlays remain open when the POS screensaver is loaded [^1]. #### Steps to reproduce: - Open the POS interface. - Open a dropdown/popover menu (e.g., the navbar hamburger menu). - Wait for the screensaver (SaverScreen) to trigger due to inactivity. - The open dropdown menu remains visible on top of the screensaver. #### Issue Dropdowns and popovers are rendered as active overlays outside the main screen container. While the screensaver setup closes active dialogs, it does not handle active overlays. #### Fix Retrieve the overlay service in SaverScreen and close all active overlays during its setup phase using a dedicated `closeAllOverlays` method. [^1]: 
2 changes
Enhancements to existing features
This update allows developers to pass custom context information directly through search bar fields in Odoo. This provides more control over how search results are filtered, potentially improving data accuracy and relevance for users. It's a minor improvement that enhances the flexibility of Odoo's search functionality.
Original PR description
Allow using `context="{...}"` in `search` views' `field` tags
Eg:
```
<search>
<field name="partner_id" context="{'ctx_key': ctx_val}"/>
</search>
```
will propagate `{'ctx_key': ctx_val}` to `res.partner`'s context when `name_search()` is called.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prResolved issues and error corrections
This update resolves a performance issue in the Point of Sale system related to concurrent sales of products. The previous approach caused delays and slowdowns for users, particularly when multiple sales locations were active simultaneously. This change reverts a previous fix to stabilize the system and improve overall responsiveness.
Original PR description
This reverts commit 787223c. In the point of sale, concurrent sales of the same product can happen, e.g. if several physical points of sales are open at the same time, each with their own session. In the case where the underlying product's valuation is tracked automatically and perpetually, the creation of the pos order leads to the creation of the stock picking, which in turn leads to a search for the next available svl. Because of the flush_all, this can cause lots of retry failures and associated delay/latency/overall perceived slowness for the end user. opw-6206709