Daily updates from Odoo
Thursday, March 5, 2026
55 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where new chart types added to Odoo weren't clearly identified in the data selection menus. By adding placeholder names, users can now easily distinguish between different chart types when building reports. This ensures accurate and efficient chart creation.
Original PR description
We recently added a lot of chart types that handle Odoo data but we faialed to add a placeholder name (which is handy to differentiate them in the datasource menu). Task-5979722 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#251135
This update fixes an issue where combo product prices were being incorrectly doubled. The change ensures that only the individual item prices within a combo are summed, preventing inflated totals. This improves the accuracy of combo pricing for customers.
Original PR description
Combo product prices were doubled in the `comboTotalPrice` and `comboTotalPriceWithoutTax` getters, as we were summing the `displayPrice` of all the combo lines, including the parent line, which already had its `displayPrice` as the sum of its children. So now, we filter out the parent line in those getters before summing. Forward-Port-Of: odoo/odoo#247347
This update fixes a previous error that prevented users from sending follow-up reports by post when they lacked sufficient permissions to modify company settings. The fix allows for necessary changes to be made as an administrator, ensuring reports can be successfully sent without interruption. This resolves a potential roadblock in the report delivery process.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to modify the res.company model Fix: modifying the external_report_layout_id as sudo opw-5482855 Forward-Port-Of: odoo/odoo#248677
This update fixes an issue where resource calendars incorrectly calculated working hours when using full-day periods. The system now averages the start and end times of a shift to ensure accurate half-day calculations, resolving a potential discrepancy in scheduling and reporting. This ensures resources are scheduled correctly across all working periods.
Original PR description
### Steps to reproduce: - Go to any working schedule of an employee. - Add a working hour line for any day and choose day period as full day. - Change work from 10:00, and work to 18:00. ### Issue: - Resource was explicitly setting 12 if any hour_from/hour_to was missing. - Resource always consider that the working time is 8AM-5PM. ### Fix: - We will calculate the avg of working hours( hour_from + hour_to)/2 - Doing this we will always get the middle of day. task: 5912748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247756
This update resolves a technical issue where incorrect partner IDs were being assigned during stock dropshipping operations. The fix automatically filters out invalid 'False' values, ensuring data integrity and preventing errors when assigning partners to shipments. This improves the reliability of the dropshipping process.
Original PR description
**Issue:** The error is produced due the changes introduced in this https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f commit. Particularly because of this assertion…
**Issue:**
The error is produced due the changes introduced in this https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f commit. Particularly because of this assertion checking :
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/odoo/orm/models.py#L5207
This assertion is failing because of the condition related to `is_dropship`. When `is_dropship` is `True`, the `partner_id` is expected to be `p.sale_id.partner_shipping_id.id`
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95
However, for the specific picking record in some cases, `sale_id` is not set
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/sale_stock/models/stock.py#L190
As a result of the current implementation, the [expression](https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95) evaluates to **False**. That False value is then included in the generated list.
**For example** : lot.partner_ids = [2, False, 5, 6]
With the recent changes, when this assignment happens, it **no longer ignores False values**. Instead, during the write process, the ORM internally calls **browse()** on the provided IDs. Since False is not a valid ID, the assertion inside browse() **fails**, this can be seen in the **traceback**.
This shows that when the field is being written, the ORM validates the IDs by calling browse(), and since False is included in the list, the assertion fails.
**Solution:**
To resolve this issue, I have use `mapped. As 'mapped()' will filter out all the empty(False) values from the recordset.
By switching to **mapped()** and returning a recordset instead of a list of IDs, False values are automatically excluded. As a result, no invalid IDs are passed to browse(), and the assertion error is avoided.
I have also added the if `p.is_dropship and p.sale_id.partner_shipping_id` condition because it fallback to the picking partner if there is no sale order partner to use
**Other Optimization:**
I have used `with_prefetch` to fetching `picking_ids`, it is just the purely ORM friendly optimization.
It ensures that all related records are prefetched efficiently across lots. It is not related to the bug above mentioned.
**Traceback:**
```python
File "/home/odoo/src/odoo/saas-19.1/addons/stock_dropshipping/models/stock.py", line 95, in _compute_partner_ids
lot.partner_ids = list(p.sale_id.partner_shipping_id.id if p.is_dropship else p.partner_id.id for p in picking_ids)
^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1866, in __set__
self.write(protected_records, value)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 765, in write
self.write_batch([(records, value)])
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 786, in write_batch
self.write_real(records_commands_list, create)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 1553, in write_real
comodel.browse(
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5202, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), "Invalid falsy real id"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
opw: 5922525
upg: 3889582
tgb: 2449
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249047This update resolves a technical error preventing users from hearing incoming ringtones during VOIP calls. The previous code was attempting to access a missing component, resulting in a system error. This fix ensures that ringtones play correctly for users, improving the call experience.
Original PR description
requestIncomingRingtone() was calling this.ringtoneService.incoming.play(), but ringtoneService is not defined on UserAgent, leading to: ``` TypeError: Cannot read properties of undefined (reading 'incoming') when handling VOIP:PLAY_INCOMING. ``` Forward-Port-Of: odoo/enterprise#109480
This update fixes an issue in the batch transfer report where product lines were scattered, making it difficult for operators to quickly locate items. The report now sorts move lines by product, grouping similar products together for faster and more accurate picking, reducing wasted time and potential errors.
Original PR description
Issue Before This Commit: ======================= In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document…
Issue Before This Commit: ======================= In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`. Steps to Reproduce: ======================= - Install the `stock_picking_batch` module. - Create `multiple deliveries` with several `common products`. - Add these deliveries to a batch transfer and print the batch transfer report. - Observe that product lines are ordered by location and then by picking. Cause of the issue: ======================= The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document. After This Commit: ======================= In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable. TaskID-5379367 Forward-Port-Of: odoo/odoo#241809
This update fixes an issue where manually created stock transfers without references were incorrectly merging into existing transfers. The change ensures each manual transfer creates its own distinct operation, preventing data inconsistencies and improving the accuracy of multi-step stock workflows. This improves the reliability of inventory management.
Original PR description
*: purchase_stock Issue Before This Commit: ====================== In a `multi-step` configuration, while validating a transfer that has no `stock reference`, its next operation (Input → QC → Stock)…
*: purchase_stock
Issue Before This Commit:
======================
In a `multi-step` configuration, while validating a transfer that has no `stock reference`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a stock reference, even when the transfers are manually
created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together.
Steps to Reproduce:
======================
- Install the `stock` module.
- Configure the warehouse to use `three-step reception`.
- Create and validate two receipts for Product A (qty 10) with Vendor A.
- `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were
created manually and not generated from any same source document like PO/SO.
Cause of the Issue:
======================
In the `_search_picking_for_assignation()` method, when no `stock.reference`is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves
without a `reference_ids` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common stock reference.
After this Commit:
======================
The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `stock.reference`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a stock reference. This ensures each manual transfer creates its `own next operation` in multi-step routes.
Task-ID: 5242340
Forward-Port-Of: odoo/odoo#251827
Forward-Port-Of: odoo/odoo#235423This update corrects a test case within the quality control module to reflect a recent change in how stock transfers are handled. Specifically, the test now accurately assesses scenarios where stock references are required for merging transfers, ensuring data integrity and consistent behavior. This resolves a potential issue impacting how quality checks are performed.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a stock reference is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#109428 Forward-Port-Of: odoo/enterprise#99342
A test was failing due to a time zone discrepancy in the planning module. The fix corrects a calculation error related to how the current date is determined, ensuring the test now passes consistently. This resolves a potential instability in the planning functionality.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e Forward-Port-Of: odoo/enterprise#108891
This update corrects a minor display issue in the accounting dashboard. Previously, the 'Reconnect Bank' button was incorrectly shown for accounts without an expiration date due to a technical detail in the code. Now, the button only appears when an expiration date is present, ensuring a cleaner and more accurate user interface.
Original PR description
The aim of this commit is fixing the behavior of Reconnect bank button in accounting dashboard. Before this commit, a synchronization without any expiring date will always show the Reconnect bank button in the accounting dashboard because the expiring due days (in the JS widget) is null and not undefined. This condition led to check the second part of the condition where null <= 0. Which is true in javascript. Now, we are checking the type of expiring due days as first condition, if it's not a number, we don't check the second part of the condition, and then we don't display the Reconnect Bank button. no task id Forward-Port-Of: odoo/enterprise#109414
This update resolves a problem preventing the correct generation of CSV reports for Peru-specific accounting. The fix addresses an incompatibility between Python 3.13 and CSV formatting, ensuring reports are created accurately. The change also streamlines the CSV configuration process for improved efficiency.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109437
Forward-Port-Of: odoo/enterprise#109081This update ensures the tour in Odoo starts correctly after a browser refresh. It prevents errors caused by the tour being triggered before it's fully registered, improving test stability and user experience.
Original PR description
Add a `waitUntilTourRegistered` helper to ensure a tour is present in the client-side registry before starting it. After a browser refresh, the tour definition may not yet be loaded when execution resumes. This could cause the tour to abort because it is triggered before being registered. The new helper waits up to 5 seconds for the tour to be available, preventing race conditions and improving test stability.
This update improves the Gantt editor within Odoo Enterprise by allowing all integer fields to be used with the color selection feature. Previously, only fields directly visible in the editor's view could be chosen. This change provides greater flexibility for visualizing project timelines and tasks.
Original PR description
Before this commit, only fields already present in the view were selectable for the color field in the gantt editor. After this commit, all int fields of the model are available task-5981029 Forward-Port-Of: odoo/enterprise#109189
This update enables cashiers to record multiple payments for a single order in the Point of Sale system. Previously, users were limited to one cash payment line, causing issues when multiple people paid separately. This change improves the user experience and accurately reflects scenarios like groups paying together.
Original PR description
Before this commit: ============ - The user is not able to process multiple cash payment lines. An error pop-up appears saying `There is already a cash payment line.` After this commit: ============ - The user can process multiple cash payment lines. Use Case: ----------- - If a group of people goes to a restaurant and one person leaves earlier, he decides to pay $10 at the cashier and leave. When the others pay later, the cashier will see that $10 has already been paid and can add another cash payment line for the remaining amount. Task-5969853 Forward-Port-Of: odoo/odoo#250639
This update corrects an issue where the display of shift durations in the Planning app was inaccurate when shifts spanned across multiple days. Specifically, the system incorrectly truncated shift names when the duration was less than 3 hours. The fix removes outdated logic related to snapping to the grid, ensuring accurate shift duration display across all durations.
Original PR description
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an…
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an employee from 3pm to 2am (over two days) - The hours of the shift are displayed - Modify the shift end to 3am - The hours of the shift aren't displayed ### Cause: Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c). But as the pills are no longer truncated since 17.0, the computation of pill names is faulty. ### Solution: We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it. opw-5881532 Forward-Port-Of: odoo/enterprise#109397 Forward-Port-Of: odoo/enterprise#107233
This update fixes a limitation where managers needed a specific group to access their team's voip call records. By changing the access rule to the standard 'group_user' group, all managers now automatically have access, simplifying permissions and improving usability. This ensures consistent access for managers without requiring additional group assignments.
Original PR description
voip_hr defines a record rule that gives managers access to their subordinates' voip.call records. However, this rule is linked to the group 'hr.group_hr_user', which is not granted to all managers. This commit links the rule to the base.group_user group instead, so that all managers can access their subordinates' records without the need for an additional group. [Task-5363640](https://www.odoo.com/odoo/project/5778/tasks/5363640). Forward-Port-Of: odoo/enterprise#100691
A test related to video calls in the Odoo chat window was failing intermittently. This change ensures the test receives the correct data at the start, preventing a delayed data fetch that caused the video to not display properly. This fix addresses a technical issue without impacting the core call functionality.
Original PR description
Test `auto-focus participant video in one-to-one call in chat window` failed non-deterministically at the following step: ``` .o-discuss-CallParticipantCard[aria-label='Batman'] video ``` This issue…
Test `auto-focus participant video in one-to-one call in chat window` failed non-deterministically at the following step: ``` .o-discuss-CallParticipantCard[aria-label='Batman'] video ``` This issue happens because very late in test there's a debounced store fetch of `channels_as_member` from receiving a new message, a call notification, and these store data contain outdated rtc session data, some of which are on `camera_is_on` being `false` instead of `true` that is simulated just prior to the failing step that expects showing of video stream on UI. This commit solely fixes the test by forcing a `channels_as_member` fetch at the very beginning of the test, as to prevent risk of such a late fetch of store data that contains the outdated rtc session data. Note that this test shows a genuine problem and there's ongoing work to solve it (see Task-4966085). This commit merely fixes the test to not show this problem that is out-of-scope of the intent of the test. Fixes runbot-error-240554
This update fixes an issue where clicking an icon within a link's popover didn't work as expected. The fix ensures that link popovers open and function properly when a user clicks on an icon inside the link, improving the user experience for links containing icons.
Original PR description
Problem: When a link contains an icon, clicking on the icon does not properly open the link popover. The popover opens and immediately closes. Cause: The logic for opening the link popover does not handle the case where the selection is not collapsed and is around an icon inside a link. This scenario was not covered in the existing conditions. Solution: Handle the non-collapsed selection case similarly to images: if the selection is around an icon inside a link, the link popover should open correctly. Steps to reproduce: - Add a link. - Insert an icon inside the link. - Click on the icon. - Observe that the link popover opens and closes immediately. task-5921393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue in the India payroll localization where a download button remained visible when the payment mode was set to 'Manually'. The fix ensures the button is hidden correctly, preventing confusion for users. This change improves the user experience for employees using the India payroll system.
Original PR description
Problem ------------------ When the user selects the "Manually" payment mode in the employee payslip, there is nothing to download but the download button is still visible. Affects all companies but only when the India Payroll localization is enabled. Objective -------------------- The Payslip Payment Wizard for the India payroll localization changed the conditions to hide the download button, so when the localization is enabled, all views are overwritten and the button becomes visible for all companies when "Manually" payment mode is selected. Solution ---------------------- Add the manual payment mode to the list of conditions to hide the download button in the l10n_in_hr_payroll localization. Task: 5975685
This update resolves an issue where the Odoo tour would sometimes fail to start after a browser refresh. The change adds a simple delay to ensure the tour is fully loaded and registered before execution, resulting in more reliable tour functionality. This improves the overall user experience and test stability.
Original PR description
Add a `waitUntilTourRegistered` helper to ensure a tour is present in the client-side registry before starting it. After a browser refresh, the tour definition may not yet be loaded when execution resumes. This could cause the tour to abort because it is triggered before being registered. The new helper waits up to 5 seconds for the tour to be available, preventing race conditions and improving test stability. 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
A test failure related to invoice data formatting was resolved. The fix ensures the correct invoice data is used in a key process, preventing potential errors and ensuring proper invoice generation for Turkish VAT invoices. This improves the reliability of the invoicing system.
Original PR description
In the `test_which_service_to_call` test, we are calling `_call_web_service_before_invoice_pdf_render` with invoice_data. But invoice_data is just a dict with `invoice.read()` and the extra key extra_edis. Instead of manually building invoice_data, we should call `_get_default_sending_settings`, which is meant to be used in the base `account.move.send` flow. Why this fix? Because by not calling `_get_default_sending_settings`, we risk changing the expected invoice_data format used in `_call_web_service_before_invoice_pdf_render`, which could lead to KeyErrors. Spotted while developing https://github.com/odoo/enterprise/pull/80590, the test failed, raising the ['invoice_edi_format'] key error. no-task Forward-Port-Of: odoo/odoo#251885 Forward-Port-Of: odoo/odoo#232105
This update fixes a potential issue with how the Odoo command-line interface handles data directories. While the recommended method is using the odoorc configuration file, this change ensures that the `--data-dir` option is consistently enforced by the platform, providing greater stability.
Original PR description
The prefered way is to use the odoorc config file, but some plateforms let their users configure their config file, but --data-dir should be enforced by the plateform. Forward-Port-Of: odoo/odoo#251937
This update corrects a minor display issue with employee names in the HR module. Specifically, it ensures that the help text associated with employee name fields is correctly copied, improving the user experience and data consistency. This change is a simple fix to enhance readability.
Original PR description
Copy string and help field attributes for virually related employee fields. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251809
This update resolves an issue preventing the export of Eco-Voucher reports from the Belgian payroll module. The change addresses a technical update related to versioning changes, specifically removing a deprecated 'state' field and aligning it with the new version module. This ensures accurate Eco-Voucher reporting for Belgian companies.
Original PR description
Since the switch from contracts to versions, exporting Eco-Vouchers to excel has not been functional, this commit fixes this. **Steps to reproduce:** - Open Payroll App as a Belgian company - Under Reporting Menu, select Eco-Vouchers - Try exporting with XLSX **Issue:** Since introduction of versions, version module does not contain state field anymore which was present in contracts **Fix:** Removed the state field and replaced it with the corresponding field in version. task:5163668 Forward-Port-Of: odoo/enterprise#109500 Forward-Port-Of: odoo/enterprise#97375
This update fixes an issue where large company logos on customer documents were overlapping with important address information. By adding a maximum width constraint to the small company logo, the document layout is now cleaner and more professional, ensuring critical customer details are always visible. This improves the overall presentation of customer documents.
Original PR description
**Description of the issue/feature this PR addresses:** Similar issue described in: https://github.com/odoo/odoo/pull/249432 Since there is no `max-width` defined for `o_company_logo_small`, if a user uploads a large logo, the customer address overlaps with the company details. This can be tested by previewing the document with a large logo. <img width="684" height="449" alt="image" src="https://github.com/user-attachments/assets/aa2ac10b-cb0f-448a-ade3-6e7bb8b1fcff" /> **Current behavior before PR:** <img width="681" height="383" alt="image" src="https://github.com/user-attachments/assets/cf7d5740-db51-43e3-b8f6-70325e9e28c0" /> **Desired behavior after PR is merged:** <img width="505" height="307" alt="image" src="https://github.com/user-attachments/assets/b175a06a-cde0-4808-a1fb-276fd96272c3" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr cc @ForgeFlow Forward-Port-Of: odoo/odoo#251976
This update corrects a bug related to invoicing in Saudi Arabia. Previously, invoices created with a date and time in SA could be incorrectly set to a future date, leading to rejection by ZATCA. This fix ensures invoices are always created with a valid date and time, respecting Saudi Arabian time zones.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250999 Forward-Port-Of: odoo/odoo#246311
This update fixes a rounding discrepancy in early payment discounts, specifically when 'Always (upon invoice)' cash discount tax reduction is used. Previously, discounts were calculated line-by-line, leading to minor discrepancies. This change ensures discounts are rounded globally for accurate calculations, improving financial reporting.
Original PR description
**PROBLEM** There is a rounding issue with early payment discount when cash discount tax reduction is set to always (upon invoice). The move.line created for the discount is computed by applying the discount to each line, rounding each line individually. But the early payment discount is computed by rounding globally. **STEP TO REPRODUCE** 1. Create a payment term, with early discount of 1%, and cash discount tax reduction set to 'Always (upon invoice)'. 2. Create an invoice with 4 identical lines, unit price 4.76€ and tax 15%. 3. set the payment term on the invoice and save. 4. Go to journal item, early payment discount is 0.20€. 5. toggle discount_amount column on the the journal item tab. 6. notice on the last line, that balance - discount_amount = 0.19€ instead of 0.20€ opw-5865308 Forward-Port-Of: odoo/odoo#251138 Forward-Port-Of: odoo/odoo#247996
This update resolves an issue where sales staff couldn't change or reset payment tokens in subscriptions due to an access error. A recent change in how Odoo calculates payment token display names triggered this error. This fix ensures that the display name for payment tokens is correctly computed, allowing users to manage their payment information as intended.
Original PR description
Use case: - install `payment_sepa_direct_debit` module. - As salesman go to a subscription and try to change/reset the payment token field. When trying to get the values of the `payment_token_id` fields [`name_search()` call] an `AccessError` is raised saying that we don't have access to `payment.provider` model. Since odoo/odoo@a3eef91230e0, fetch() do compute fields, so for payment token this means that `display_name` will be computed without su=True flag, thus it may raise an `AccessError` if accessing some payment provider fields. So this commit force building token display name as sudo, to ensure it can be correctly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251996
This update fixes an issue where taxes weren't correctly applied when the tax's fiscal position was set to 'all'. The change ensures that taxes with this setting are now applied appropriately, aligning with expected behavior. This resolves a discrepancy between the sales order's fiscal position and the actual tax application.
Original PR description
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case…
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case `all` will be shown in placeholder. 2- Set Domestic FP to be applied automatically, and set the country to `US`. 3- Create a Partner with `US` country_id. 4- Create a product, and apply the created tax to sale taxes. 5- Create a SO with created partner and the created product. 6- As you see, the tax is not applied to the line, while if you check SO's fiscal position, it is set to Domestic. Expected: As tax's fp is set to all, we expect this tax being applied with Domestic fp. ### Cause: In this line, if no `tax_ids` is set, it means fp has not tax_ids: https://github.com/odoo/odoo/blob/0c3ae7f78d313885984c99a4e57485d9660dd974/addons/account/models/partner.py#L154-L158 However, this might also mean the tax has no fp because `fp.tax_ids` is a Many2Many relation. In the forms, `tax.fiscal_position_ids` being empty is shown as `all` in the placeholder, which means when no tax applied to fp, we expect all taxes to be mapped. ### Fix: This can be fixed by making sure the fp.tax_ids is not empty because there is no `tax.fiscal_position_ids` set. ### Remark: In this fix we rename `TestInvoiceTaxes._create_invoice` to `_create_invoice_taxes_per_line` to avoid override of `AccountTestInvoicingCommon._create_invoice`. This is already done on saas-19.1+. opw-5463245 Forward-Port-Of: odoo/odoo#251872 Forward-Port-Of: odoo/odoo#244155
This update fixes an issue where the price per unit was incorrectly displayed in the shopping cart when products were purchased with packaging. The fix ensures that the price per unit accurately reflects the product's price divided by the actual quantity purchased, resolving a discrepancy in the displayed cart totals. This improves the accuracy of pricing information for customers.
Original PR description
Issue: --- Due to this issue, price per unit is not shown correctly in case of packaging. Steps to reproduce: --- 1- Create a product. Set price: 2.6 per kg. Set `Base Unit Count` to 1. 2- Create a…
Issue: --- Due to this issue, price per unit is not shown correctly in case of packaging. Steps to reproduce: --- 1- Create a product. Set price: 2.6 per kg. Set `Base Unit Count` to 1. 2- Create a packaging of 0.5 kg, and add it to product in Sale tab. 3- Navigate to the shop and add 0.5 kg of the product to cart. 4- Navigate to the cart. Expected: The line price/unit should be 2.60/kg. Current outcome: It's shown 1.30/kg. Cause: --- Currently `_get_base_unit_price(product_price/line.product_uom_qty)` is shown to user as price/unit. `product_price` is calculated using `_get_cart_display_price()` which returns each line's `subtotal` or `total`. In our case, it will be `_get_base_unit_price(1.30/1)`, having base_unit_count set to 1, we will have 1.30 which is wrong. Fix: --- We would need to divide the line price by `product_qty` instead of `product_uom_qty`. Then in our example we would have: `_get_base_unit_price(1.30/0.5) = 2.60`. opw-5973097 Forward-Port-Of: odoo/odoo#251860 Forward-Port-Of: odoo/odoo#251501
This update optimizes the ZATCA onboarding process for journals by reducing memory usage. Previously, a lengthy check looped through all journal entries, causing errors with large volumes of data. Now, the system directly searches for relevant documents, significantly improving performance and stability.
Original PR description
Behavior before: Sanity check looped over all account moves of the journal, filtering in Python for ZATCA documents. This caused memory errors when the journal had hundreds of thousands of moves. Behavior after: The check now searches directly on l10n_sa.edi.document with a domain that filters only relevant moves with state 'to_send', reducing memory usage and avoiding Python-level loops. Root cause: Loading all moves and their One2many edi_document_ids in memory for filtering caused excessive memory usage and MemoryError on large journals. OPW-5972073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251732
This update corrects a recent issue in the l10n_ch_hr_payroll module by reintroducing the calculation of contractual annual wages. This ensures accurate payroll processing for Swiss businesses using this module, aligning with local tax regulations and improving financial reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#109264 Forward-Port-Of: odoo/enterprise#109228
This update optimizes Odoo's database queries by preventing unnecessary SQL generation, particularly for complex field relationships. Specifically, the system now avoids generating slow SQL when accessing related fields like email content, improving overall performance and reducing resource consumption. Additionally, certain models with intensive access checks have been optimized for faster processing.
Original PR description
## [FIX] orm: stop generating slow SQL Update the context variable to cover the case where we have a related field such as "mail_message_id.body" which is not ran un sudo. In that case, we don't want to generate the SQL. ## [FIX] orm: _access_domain_heavy Mark some models that have heavy access checks so that they can be handled in a special way for performance reasons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249283
This update fixes an issue where SMS reminders weren't being sent for calendar events synced with Google or Microsoft. The fix ensures that Odoo correctly handles SMS notifications for these synced events, aligning with the intended behavior of email reminders being delegated to Google. This improves the reliability of reminders for all users.
Original PR description
SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google. Reproduction steps: * Create a calendar event in Odoo with an SMS…
SMS reminders are not sent for calendar events synced with Google, even though only email reminders should be delegated to Google. Reproduction steps: * Create a calendar event in Odoo with an SMS reminder. * Sync the calendar with Google. * Wait for the reminder to trigger. * Observe that no SMS is sent by Odoo. Cause: The event reminder scheduled action groups events by alarm type and calls `_get_events_by_alarm_to_notify`. For Google-synced events, `_get_notify_alert_extra_conditions` blindly excludes any event with a `google_id`, assuming Google will manage all reminders. This exclusion is incorrect for non-email alarms (e.g. SMS), which must still be handled by Odoo. Fix: The alarm type is propagated through the context so Google-specific exclusions only apply to email reminders. This restores SMS notifications while preserving the existing behavior for emails. A context key is used for stability; a proper method argument will be introduced in master. opw-5172958 Forward-Port-Of: odoo/odoo#251742 Forward-Port-Of: odoo/odoo#241026
This update resolves a bug where the cursor would disappear when replying in the HTML composer, particularly in Firefox. The fix involves adding invisible characters around mentions to ensure proper cursor movement and text insertion, improving the user experience for composing messages.
Original PR description
In chatter, using "Reply" in HTML composer could focus the composer without giving a usable caret. The inserted partner mention is a non-editable link (`contenteditable="false"`), and selection could end up inside that node, so typing would not insert text. This also fix the related firefox issue: mentions are rendered as `a[contenteditable=false]`. Firefox is stricter than Chrome for carret positions around non-editable inline nodes, so clicking before a mention or moving left from its right edge could make stuck. so we register mention selectors as FEFF providers in the mention plugin. (a feature of html_editor FEFF plugin to add invisible boundary characters around mentions, which gives firefox what it need to move carret around. some tests had to be adapted to take the insertion of FEFFs in the composer text into account task-5262368 Forward-Port-Of: odoo/odoo#250711 Forward-Port-Of: odoo/odoo#250296
A technical issue was causing the Activity Logs report to appear incorrectly within the Sign Template list view, leading to errors. This update corrects a misconfiguration in the report's model settings, ensuring it now displays correctly within the Sign Request view and resolves the underlying error.
Original PR description
Version: - saas-18.2 Issue: - The "Activity Logs" report was showing in the Sign Template list view. When clicking it, a traceback occurred because the report tried to read a `sign.request` record from a `sign.template` context. Cause: - The report model was set to `sign.request`, but the`binding_model_id` was set to `model_sign_template`. - This mismatch caused the report to appear in the wrong place. Solution: - Updated the `binding_model_id` to `model_sign_request` so the report now appears in the Sign Request view, which matches the report model and prevents the error. task-5984137 Forward-Port-Of: odoo/enterprise#109171
This update resolves an issue where filtering by 'Analytic Distribution' (set/not set) in journal entries and purchase orders produced incorrect results or errors. The fix ensures accurate filtering by correctly handling boolean values related to analytic distribution accounts, improving data accuracy and reporting.
Original PR description
**Problem:**
When filtering by "Analytic Distribution" in views, using "is set" or "is not set" filters (or searching for False) causes a "search domain not valid" error or returns incorrect results.
**Steps to reproduce:**
1) Go to Accounting > Journal Entries.
2) Apply a filter for Invoice lines > Distribution Analytic Account.
3) Select "is set" or "is not set".
4) Check records.
Issue produces error "search domain not valid". Also reproduceable on Purchase Orders.
**Cause:**
The `_condition_to_sql` method did not handle the `('=', '!=')` operators early enough, so it always went to the "operation not supported" error.
**Solution:**
- We need to move the handling of the operators '=', '!=' early enough in the `_condition_to_sql` method.
opw-5478688
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251816
Forward-Port-Of: odoo/odoo#247777This update fixes an issue where combo product refunds weren't correctly handling orderlines with quantities exceeding the combo's total. Now, the system accurately refunds the full quantity of each item within a combo, regardless of individual orderline amounts. This ensures accurate refunds for complex combo orders, improving the user experience.
Original PR description
When refunding a combo item, the 'To Refund' text would always show the same quantity for all the orerlines as for the combo. But combos could have orderlines with a higher quantity than the combo itself (i.e. 3 menus with 2 burgers each - 6 burgers in total. Now the POS would only let us refund up to the limit qty of the combo, so 3 instead of all 6 burgers) After the fix, we check the quantity of each line in the combo and we refund the full quantity (i.e. if you have a 3 menus with 2 burgers each - 6 burgers in total. The burgers will be divided per combo, so each menu refund will automatically refund 2 burgers.) Task-[5503962](https://www.odoo.com/odoo/project/1737/tasks/5503962) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248212 Forward-Port-Of: odoo/odoo#244702
This update corrects a bug where the system was incorrectly returning multiple bank records due to duplicate account numbers, particularly when dealing with child company contacts. The fix ensures that only one bank record is created, streamlining bank management and preventing data inconsistencies. This improves data accuracy and reliability.
Original PR description
The function `_find_or_create_bank_account` is expected to return one or no record at all. In the case of child contacts, it is possible that the same account number was set on multiple records, leading the function to return multiple banks. Forward-Port-Of: odoo/odoo#251733
This update fixes a technical issue within the mass mailing module that ensured the correct identification of editable elements. Previously, the system incorrectly interpreted a shared method, leading to potential inaccuracies. This change improves the reliability and accuracy of mass mailing operations.
Original PR description
Description of the issue/feature this PR addresses: This PR makes sure `isSelectionInEditable` is correctly checked in `EmptyNotEditableElementsPlugin`. `isSelectionInEditable` is a shared method previous code interpreted it as property. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251744
This update optimizes the HTML editor's performance by reducing unnecessary layout recalculations. Specifically, the code now prioritizes reading the layout before making changes to the DOM, leading to a smoother and faster user experience. Additionally, frequent updates are now controlled to prevent performance issues.
Original PR description
Description of the issue this PR addresses: I. The power buttons positioning logic was interleaving DOM writes and layout reads during selectionchange, causing repeated style/layout recalculations.…
Description of the issue this PR addresses: I. The power buttons positioning logic was interleaving DOM writes and layout reads during selectionchange, causing repeated style/layout recalculations. This PR reorders the logic so geometry is read first and DOM mutations are applied afterwards, reducing the number of forced reflows and significantly improving performance. II. Debounce `updateHints` and `updatePowerButtons` to avoid excessive UI updates on frequent selection changes. Introduce `debounceHints` and `debouncePowerButtons` editor config options so debouncing can be disabled in tests for deterministic behavior. III. Introduce READ helper for withSequence to explicitly order resource handlers so DOM reads run before DOM mutations. Before: <img width="1705" height="399" alt="image" src="https://github.com/user-attachments/assets/2fca797a-0311-4c4a-9063-2051934baa7c" /> After: <img width="1490" height="343" alt="image" src="https://github.com/user-attachments/assets/0f295969-b962-4190-a7f9-fe5366d7fafd" /> task-5499625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252001 Forward-Port-Of: odoo/odoo#244478
This update resolves an issue where US-specific reports were incorrectly appearing in Odoo databases set up for India. The fix ensures that the necessary US Payroll module is automatically installed when the base HR Payroll module is installed, preventing this unexpected report visibility. This improves the user experience for international clients.
Original PR description
**Version:** saas-19.1 **Steps to reproduce:** - Create a new database with India as country. - Install l10n_in_hr_payroll. - US company based reports are visible. **Issue:** Reports specific to us payroll localisation are visible for base hr_payroll module **Cause:** The l10n_us module was missing as the auto_install dependency. **Solution:** Added l10n_us as the auto_install dependency in the manifest file. **task-5948747** Forward-Port-Of: odoo/enterprise#108435
This update resolves a technical issue preventing the holiday calendar tour from functioning correctly in certain situations. The fix ensures the tour consistently displays and operates as intended, improving the user experience. This change was identified and addressed through automated testing.
Original PR description
This fix adjusts the tour in `test_hours_time_off_request_calendar_view` as it was failing in some cases. runbot error 237682 Forward-Port-Of: odoo/odoo#249458 Forward-Port-Of: odoo/odoo#249267
This update corrects a persistent warning message appearing after deleting a payslip in the HR payroll system. The fix involves canceling the payslip before deletion to ensure accurate duplicate checks, preventing unnecessary warnings. This improves the user experience and data integrity.
Original PR description
### Steps to reproduce: - Create two payslips for the same employee for the same period. - Delete one of them; the duplicate warning still appears on the other payslip. ### Fix: - Before deleting a payslip, first cancel it so the current payslip can be skipped while checking for duplicate payslips. - Then trigger recompute _compute_issues for duplicates payslips task: 5427473 Forward-Port-Of: odoo/enterprise#104124
This update fixes an issue where analytic asset depreciation reports weren't accurately distributing amounts when the analytic filter was enabled. The change ensures that depreciation calculations now correctly reflect the distribution of amounts across the relevant analytic accounts, improving the accuracy of financial reporting.
Original PR description
Previously, when the analytic filter is enabled in the depreciation schedule, the total depreciation amount was shown in each respective depreciation column, and the analytic distribution was not taken into account. This commit fixes the depreciation amount for assets with analytic distribution in the depreciation schedule report. When the analytic filter is enabled, the amounts are computed correctly under each analytic's depreciation column. task-5959962 Forward-Port-Of: odoo/enterprise#108484
A recent update caused a disruption in our SEPA direct debit payment processing. Customers were unable to complete payments using this method due to a technical error. This fix resolves the issue by correcting a missing data element, restoring functionality for SEPA direct debit payments.
Original PR description
Issue: --- The SEPA direct debit is broken. Steps to reproduce: --- 1- Enable SEPA direct debit in payment providers. 2- Add something to cart and try paying using SEPA direct debit. You get the error: `payment.provider object has no attribute company.` Cause: --- This is introduced after #250326. opw-5993720 Forward-Port-Of: odoo/enterprise#109672
This update fixes an inconsistent spacing issue in the Poll Result message displayed in the message list. Previously, there was extra space above the poll result box, which has now been removed. This ensures a cleaner and more professional look for all users.
Original PR description
Before this commit, Poll Result in message list had some unwanted spacing between the message header and the poll result box. The bottom spacing is fine but not the top. Before / After <img width="263" height="161" alt="Screenshot 2026-03-04 at 16 44 12" src="https://github.com/user-attachments/assets/b827bc1e-ee67-4f73-bea5-3bfc3ed7ed2d" /> <img width="271" height="150" alt="Screenshot 2026-03-04 at 16 43 57" src="https://github.com/user-attachments/assets/fc816b40-f375-48f3-a283-ea064d2b4cfb" /> Forward-Port-Of: odoo/odoo#252050
This update fixes an issue where flexible resources were incorrectly displaying a total of 40 hours per week. The fix ensures that the resource's individual schedule (e.g., 38 hours) is accurately reflected when calculating available hours. This improves the accuracy of scheduling and resource allocation.
Original PR description
### Steps to reproduce: - Download Planning app - From the employees app, create an employee - Assign that employee a new schedule that is 'Flexible', has 07:36 hours/day 'Avg', and has 'Total' 38 hours/week - Search for that employee in the planning app and hover over their name ### Cause of Issue: The total available hours for that employee show as 40h. This is because when calculating the hours per week for the resource, the resource's schedule is not taken into account but the company's. ### Fix: Add the hours per week for the resource's calendar (if available) in the calculation opw-5954982 Forward-Port-Of: odoo/odoo#250185
A test within the Odoo stock module was intermittently failing due to inconsistencies between the database and the test environment. This update adds a database refresh step to the test, ensuring accurate data and preventing these random failures. This improves the reliability of our stock management testing.
Original PR description
In Signal app, the test `test_set_inventory_quant_to_zero` was failing randomly when asserting that the quant no longer exists after calling `_unlink_zero_quants()`. All required conditions for deletion were met: - inventory_quantity == 0 - user_id is False - quantity == 0 - reserved_quantity == 0 The method `_unlink_zero_quants()` performs a raw SQL query to select zero quants. Since raw SQL does not trigger an automatic ORM flush, the quant state could be out-of-sync with the database at the time of the query, making the deletion non-deterministic. Add an explicit `flush_all()` before calling `_unlink_zero_quants()` in the test to ensure the database reflects the latest ORM state and avoid random failures. Runbot-241210 Forward-Port-Of: odoo/odoo#252006
This update fixes an issue where the time was not accurately displayed in direct message conversations. The change updates how the system retrieves time zone information, ensuring correct time formatting is used for all direct messages. This improves the user experience by providing accurate time information.
Original PR description
Before this PR: The time was not displayed in direct message conversations because the timezone dependency relied on `thread.correspondent`, while the correspondent is now stored on the `channel` model since https://github.com/odoo/odoo/pull/241072. After this PR: The timezone dependency now retrieves the correspondent from `thread.channel.correspondent`, ensuring the correct timezone is used and the time is displayed properly in direct messages. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects a visual issue where the 'invalid locators' warning was appearing incorrectly within a form due to an outdated XPath targeting a duplicate element. The fix ensures the warning now displays correctly after the 'Be aware' alert, resolving a potential user experience problem. This was caused by differences in database view ordering.
Original PR description
The XPath `//div[hasclass('alert-info')]` used to insert the invalid locators warning matches multiple elements since the website module has another `alert-info` div inside the visibility field:…
The XPath `//div[hasclass('alert-info')]` used to insert the invalid locators warning matches multiple elements since the website module has another `alert-info` div inside the visibility field: https://github.com/odoo/odoo/blob/31c199f3d19b8f9c54d582b6a5c4684e1ed38d0a/addons/website/views/website_pages_views.xml#L221
<img width="1065" height="633" alt="image" src="https://github.com/user-attachments/assets/dab8955c-d01b-4682-871a-b7499ed99297" />
<img width="1427" height="986" alt="image" src="https://github.com/user-attachments/assets/a05efb5d-254b-4e3a-ad14-530ae6718be6" />
On databases created before the invalid locators feature was added, the website inherited view has a lower ID than the web one, so it is applied first. This causes the XPath to match the wrong element and places the warning in the middle of the form fields instead of after the "Be aware" alert. This is not reproducible on runbot since fresh databases always have the correct ID ordering.
<img width="2291" height="956" alt="image" src="https://github.com/user-attachments/assets/fc7eee11-c66e-4d84-b827-f2ed61c76a97" />
We now target the correct alert div that is a direct child of the sheet element. Hence, the inheriting order no longer affect the location of the warning.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251631This update resolves a rare issue in the Gantt view that could cause it to crash when users interact with search filters. The fix prevents a data loss scenario that occurred when a search filter removed a task pill while a hover event was still active, ensuring a more stable user experience.
Original PR description
This commit fixes a traceback in the Gantt view caused by a race condition during search operations. If a user clicks a search dropdown item located directly above a task pill, and that search filters out the underlying pill, a `pointerenter` event can fire on the pill just as the dropdown closes. Because the search amy already be applied, the renderer could lose track of the pill, causing the handler to crash when trying to access it. This commit adds a safety check to the event handler to exit early if the hovered pill is no longer found in the renderer. Forward-Port-Of: odoo/enterprise#109545
This update clarifies how Helpdesk articles are searched when a non-root article is selected as the main article. Previously, searching didn't include descendant articles. Additionally, a minor issue with the dropdown functionality has been addressed to prevent empty dropdowns. The team has opted to provide clearer guidance on this behavior rather than attempting a complex domain fix.
Original PR description
*: website_helpdesk_knowledge **Steps to reproduce:** - Install Helpdesk/Knowledge/Website apps - Go to Knowledge - Set up a Knowledge workspace root article with some child articles to it - Go to…
*: website_helpdesk_knowledge
**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help
First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant
Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback
**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.
This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.
The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.
**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.
Also manually reset the attribute for `_onFocusOut`.
related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11
opw-5258607
Forward-Port-Of: odoo/enterprise#109612
Forward-Port-Of: odoo/enterprise#107438This update resolves a tour test failure caused by a delay in order synchronization. The fix adds a waiting step to ensure the order is fully processed before initiating refunds, preventing a constraint error related to negative order amounts. This ensures refunds are handled correctly within the system.
Original PR description
In this commit: =============== - Fix the tour `test_mx_pos_invoice_order_and_refund` failing with **WARNING**: `The amount of the order must be positive for a sale and negative for a refund`. caused by an order sync issue with the backend. Cause: ====== - The tour started the refund immediately after validating the order, while the original order was still syncing with the backend. - Because of this, the constraint `_l10n_mx_edi_constrains_amount_total` was triggered since the order had `amount_total < 0` but `refunded_order_id` was not set yet. Fix: ==== - Add a waiting step in the tour to make sure the order is fully synced before starting the refund flow. Task: 5993576 Error: 237980