Daily updates from Odoo
Monday, January 5, 2026
6 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where refund transactions incorrectly displayed the customer as the author instead of the user who initiated the refund. The change ensures the logged-in user is always identified as the author for refund, capture, and void transactions, improving data accuracy and reporting. This resolves a potential confusion regarding transaction ownership.
Original PR description
Currently, the customer, who did not perform the operation, is set as the author of the refund, capture, and void transaction messages. **Steps to reproduce:** - Install the `sale_management` module…
Currently, the customer, who did not perform the operation, is set as the author of the refund, capture, and void transaction messages. **Steps to reproduce:** - Install the `sale_management` module and enable the `demo` payment provider. - Create a new quotation and from the `gear` icon, select `Mark Quotation as Sent`. - From the `gear` icon, choose `Generate a Payment Link`, and copy the link. - Open the link in an incognito window, and complete the payment. - Return to the original tab and open the payment transaction from the chatter. - Click `Refund` > `Refund` and observe the `author` of the messages in the chatter. **Observation:** The refund messages entry shows the customer as the author instead of the logged-in user who executed the refund. **Root Cause:** At [1] and [2], when the logged-in user is not a superuser, the code assigns the customer (`self.partner_id`) as the author, even during `refund`, `capture`, and `void transactions`, resulting in an incorrect message author. **Fix:** This commit ensures that during refund, capture, and void transactions, the message author is set to the logged-in user instead of the customer. [1]: https://github.com/odoo/odoo/blob/bbf3bd7b0e1d3e015350f9c959fad056384e2318/addons/account_payment/models/payment_transaction.py#L223 [2]: https://github.com/odoo/odoo/blob/5cf325dfff1ffbc1c4b4d0bcfc44ac9f55ea7c51/addons/sale/models/payment_transaction.py#L110 **Before:** <img width="1910" height="624" alt="5379376_before" src="https://github.com/user-attachments/assets/decdd620-d741-488e-9dec-e5c8c9bafc48" /> **After:** <img width="1917" height="622" alt="5379376_after" src="https://github.com/user-attachments/assets/5f38f3c3-fd2c-489e-afc9-d7a356fde23a" /> opw-5379376 Forward-Port-Of: odoo/odoo#241923 Forward-Port-Of: odoo/odoo#239224
This update fixes a usability issue where items within Kanban card dropdown menus weren't easily navigable or highlighted on hover. The team added a styling class to these dropdown items, ensuring they function correctly and provide a better user experience when selecting options from Kanban views.
Original PR description
Issue:
Dropdown item-ish (such as `<a class="dropdown-item">` and ViewButton) inside kanban cards dropdown do not have the proper hover styling and are not navigable.
Steps to reproduce:
- Go to project -> open any card dropdown menu ("...") -> Items are not navigable
- Go to CRM -> open any card dropdown menu ("...") -> Items are not highlighted on hover
Fix:
This commit adds the "o-navigable" class to dropdown items and view buttons
which are inside a kanban card's dropdown menu, this makes them navigable
and adds proper hover and focus styling.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#240090This update resolves a sporadic test failure related to how partner suggestions are sorted, specifically when messages are sent. The fix ensures the test accurately reflects the system's data by waiting for the necessary updates to be processed before verification, preventing inconsistent results. This improves the stability and reliability of the suggestion sorting feature.
Original PR description
Before this commit, the test "Sort partner suggestions by recent chats" fails non-deterministically due to a race condition. This failure occurs because the test relies on the `last_interest_dt` timestamp being updated after sending a message to "User 2". Although the message post triggers a bus notification to update the store, the UI displays the message optimistically. As a result, the assertion for the message's existence occasionally passes before the bus notification was processed, leaving the sorting logic to run with stale data (where "User 2" was still ranked behind "User 3"). This commit fixes the issue by waiting for the sidebar to reorder "User 2" to the top. Since the sidebar ordering relies on the same server data (last_interest_dt) as the suggestion sorting, this ensures the store has processed the bus event before the test verifies the suggestion order. runbot-237553 Forward-Port-Of: odoo/odoo#241619
This update clarifies delivery slip reports by explicitly labeling the delivery address and simplifying customer information labels. These changes reduce potential errors and confusion during order fulfillment, leading to greater operational efficiency.
Original PR description
To resolve ambiguities and improve operational efficiency: 1. The delivery address is explicitly labeled 'Delivery Address'. Ensuring no doubt about the final destination. 2. The label for the customer's primary information has been updated from 'Customer Address' to simply Customer, which prevents operators from mistaking it for the delivery point. Backport of https://github.com/odoo/odoo/pull/220019 Task: 3379926 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 an issue where the search panel in the deep hierarchy view was getting cut off. The change allows the entire hierarchy to scroll properly, ensuring full UI usability and preventing data truncation. It also stabilizes a key test case without affecting other parts of the system.
Original PR description
Issue: - The search panel was getting clipped when navigating deep into the hierarchy. - `.o_content` enforced `height: 100%` and `overflow: hidden`, preventing the hierarchy from expanding and blocking vertical scroll. - The JS test "drag node to scroll" queried `.o_content`, which is no longer the actual scrollable container in the hierarchy view, causing intermittent test failures. Fix: - Allow `.o_content` to grow and remove overflow restrictions only in the hierarchy view. - Enable vertical scrolling on `.o_hierarchy_view.o_action` to support large hierarchies. - Update the test to query `.o_hierarchy_view.o_action` so it targets the correct scrollable element. Impact: - Restores proper scrolling behavior. - Prevents search panel truncation and preserves full UI usability. - Stabilizes the hierarchy drag-scroll test without impacting other views. Task: 5326054
This update fixes an issue where helpdesk ticket creation would fail due to incorrect access checks when users were assigned to teams across different companies. The change prevents unnecessary data fetching in sudo, ensuring users only access resources within their own company, resolving a potential access error.
Original PR description
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members…
Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company. This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket. Steps to reproduce the issue: ---------------------------- 1. Install helpdesk module 2. Create a new company B 3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user 4. Select that new company created in step and go to helpdesk app. 5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team 6. log in as the user created in step 3 7. make usre the company selected is the one created in step 2 8. create a ticket in the helpdesk team created in step 5 Expected behavior: ----------------- The ticket should be created without any issue. Actual behavior: --------------- An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one. opw-5223717 Forward-Port-Of: odoo/enterprise#102859