Monday, December 8, 2025
8 changes · saas-18.2
Resolved issues and error corrections
This update resolves an issue where helpdesk ticket assignments were failing due to incorrect resource selection. The fix ensures that only resources within the same company as the helpdesk team are considered, preventing access errors and improving ticket assignment functionality. This improves stability and reliability of the helpdesk module.
Original PR description
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable…
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable auto assignment on the team - try to create a ticket on that team -> error Problem: ======== When computing working intervals for resources of the team members, we were considering all resources of the user, even those not in the same company as the helpdesk team. Which lead to access errors when trying to read data from the other company. This issue was not caught before as we were never reading data from the resources, until this [commit](https://github.com/odoo/odoo/commit/79a559c9741410ad861c107e395b2fc486da95e8) where we try reading `employee_id` of the resource. Solution: ========= Filter resources to keep only those in the same company as the helpdesk team. P.S: ==== the removed test was trying to test assigning ticket to user that is not in the same company as the helpdesk team, which is not correct so the test was removed. opw-[2749232](https://www.odoo.com/web#id=2749232&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#99614
This change eliminates a misleading warning banner that appeared during SEPA batch payments when a linked employee had an address. The system was already correctly generating reports using the employee's address, so this fix ensures a smoother user experience and avoids unnecessary alerts. This improves the reliability of batch payment processing.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346 Forward-Port-Of: odoo/enterprise#99928
This update resolves an issue where clicking a Field Service record in the kanban view opened it in the same tab instead of a new one. The fix corrects a technical error within the `industry_fsm` module that prevented the expected new-tab behavior when using a middle mouse click. This ensures a smoother user experience when accessing records.
Original PR description
Steps to reproduce: 1. Install `industry_fsm` 2. Open Field service module 3. In the kanban view, click a record with the middle mouse button Issue: - The record opens in the same tab instead of a new tab. Cause: - `FsmMyTaskKanbanRecord` overrides `onGlobalClick` without propagating the `newWindow` argument, preventing the expected new-tab behavior. Solution: - Forward the `newWindow` parameter to the parent implementation to restore the correct handling of the middle mouse click opw-5351842
This update fixes an issue where subscription details weren't correctly displayed in the dashboard. Specifically, it addressed a bug where sale order items were incorrectly shown alongside subscriptions and the subscription titles were not accurate. The change ensures subscriptions are presented clearly and accurately within the dashboard.
Original PR description
Before this commit, when subscriptions were linked to the analytic account of a project, the sale order items appears in an unwanted section when the section is unfolded. Meanwhile, when the subscription section is unfolded the title of the subscriptions items are not correctly displayed. The first issue is due to the fact that we did not correctly exclude the subscriptions items from the domain. The second issue is due to the fact that we fetch the field 'name' from the subscription search instead of the field 'display_name' task-5159781
This update fixes an issue where refunds on orders with global discounts in the Mexican localization (l10n_mx_edi_pos) could cause errors when generating invoices. The fix prevents refunds from exceeding the original order total, ensuring accurate invoice generation and avoiding potential data discrepancies. This change is specific to the Mexican localization for efficiency.
Original PR description
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to…
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization. Steps to reproduce: ------------------- * Activate the global discount option in any PoS * Open PoS and make a sale with a global discount * Refund the sale without including the discount * Go to the backend * Go to the order list and select the 2 orders you made * Now try to create a global invoice > Observation: The global invoice is in error because the negative lines cannot be distributed correctly. Why the fix: ------------ To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense. opw-4899501 Forward-Port-Of: odoo/enterprise#93101
This update corrects an issue where shipping labels for FedEx deliveries weren't including the company name entered during checkout. The fix ensures that the correct company information is used on shipping labels, improving order accuracy and customer experience. This was triggered by a discrepancy in how contact information is handled in the ecommerce system.
Original PR description
Steps to reproduce: - install ecommerce (i.e. website_sale) and delivery_fedex_rest - setup demo payment + fedex delivery method (including publishing it) - open the db while not logged in (i.e. in private browsing) - add something in the ecommerce page to cart + checkout > checkout - type in random contact info INCLUDING "Company Name" - continue checkout > select FEDEX as delivery method > pay now - go to Sales App > Sale orders > open the SO generated by ecommerce - open delivery + validate Expected result: - Shipping label with the name + company name from the ecommerce form Actual result: - company name is missing Issue is due to a company not being generated by ecommerce. Instead a string field is filled in (which is not visible when creating a contact directly via the contacts app). Code has been adapted to consider this use case. opw-5119089 Forward-Port-Of: odoo/enterprise#101376
This update fixes a technical issue that could display error messages to users during the payment process for rental events. The change prevents frontend tracebacks caused by unusual event configurations, ensuring a smoother experience for customers. While the rentable event ticket feature is being addressed, this fix improves overall stability.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `website_event_sale` but not `stock` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- Having odd configurations like rentable tickets creates rental orders without rental dates, leading to unhandled errors. Solution -------- While rentable event tickets doesn't make enough sense to make it work, we can still improve the error handling to prevent showing tracebacks to the client. opw-5207045 Forward-Port-Of: odoo/enterprise#99000
This update ensures that downpayment taxes, when calculated externally (like with Avatax), correctly use the designated downpayment account set on the product category. Previously, it defaulted to the standard income account, leading to inconsistent tax calculations. This change aligns with expected downpayment behavior and improves accuracy.
Original PR description
**Problem:** When calculating taxes externally (such as Avatax) and a downpayment is made, the line on the invoice will always use the default income account, regardless of the downpayment account set as a company default. This is inconsistent with the standard behavior of downpayments, which will use the downpayment account set on the product's category instead of the income account (which themselves may come from company defaults). **Solution:** Check if there's a company default for downpayment account on product category and use this account for the downpayment line instead of the income account. opw-5171067 Forward-Port-Of: odoo/enterprise#101524