Daily updates from Odoo
Thursday, January 15, 2026
198 changes
27 changes
Resolved issues and error corrections
This update resolves an issue where the 'Add to Cart' button on product pages was refreshing the entire page instead of opening a modal. The fix changes the button's type to 'button', ensuring the modal pop-up functionality works as intended, improving the customer's shopping experience.
Original PR description
[Issue] Customer embedded the "Add to Cart" button id="s_add_to_cart" to the [form](https://github.com/odoo/odoo/blob/edaa02dc0e67d6ccd17cc3be9a98d94276bcd403/addons/website_sale/views/templates.xml#L2066) inside the product webpage. By default, buttons inside forms use the type="submit" attribute, which causes the form to refresh after the button is clicked. Therefore, the modal pop-up is essentially rendered useless because it just refreshes the page. [Solution] added type="button" to the button inside "s_add_to_cart" to make it a normal button without the "submit" functionality opw-5417500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241694
This update resolves an issue where the 'Source Document' field was incorrectly empty after reversing invoices. This meant users couldn't easily track the original invoice linked to the reversed transaction. The fix ensures that the correct invoice origin is displayed during reverse moves, improving reporting and reconciliation accuracy.
Original PR description
### Issue: Reverse moves miss `invoice_origin` field. #### To reproduce: 1- Create a SO. 2- Create an invoice and confirm. 3- In invoice list view make the `Source Document` visible. 4- Create a credit note and reverse the move. From invoice list view, you can observe that `Source Document` is empty for reverse move. ### Cause: This is a regression introduced by #236656. opw-5362055 Forward-Port-Of: odoo/odoo#240439
A technical bug related to a record rule was causing a crash when opening contacts. This fix resolves an ambiguous column reference within the system's query logic, ensuring the contact application functions correctly. The update prevents a traceback and improves overall stability.
Original PR description
### Issue: When creating a record rule on moves using partners, a traceback is raised when opening a contact. ### Steps to reproduce: - Install 'account_followup' and 'contacts' - In Settings >…
### Issue:
When creating a record rule on moves using partners, a traceback is raised when opening a contact.
### Steps to reproduce:
- Install 'account_followup' and 'contacts'
- In Settings > Technical > Security > Record Rules create a new rule
- name: Test Rule
- model: Journal Entry
- definition: `[('partner_id.is_company', '!=', True)]`
- Open the Contact app and try to open a contact
- Traceback
### Cause:
The newly created rule is used in the query computed by `_compute_has_moves()`. To do this the tables 'account_move' and 'res_partner' are joined. Then `subselect()` simply adds the select element with the string it is given, resulting in:
```sql
SELECT commercial_partner_id
FROM "account_move"
LEFT JOIN "res_partner"
...
```
But both `account_move` and `res_partner` have a column named "commercial_partner_id" resulting in an ambiguous column reference traceback.
### Solution:
We need to add precision on which table should be used. `subselect()` cannot guess which one should be used. We cannot add the precision in the definition of `field_names` because it is not compatible with the domain used by `_search()`.
So we add `'account_move.'` to the field name before giving it to `subselect()`.
opw-5467608
Forward-Port-Of: odoo/enterprise#103792This update fixes an issue where matching a partner by bank account could inadvertently overwrite a previous match found by name. Now, the system prioritizes the bank account match, ensuring accurate partner identification when processing bank statements. This improves data reliability and reduces potential errors.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task Forward-Port-Of: odoo/enterprise#103648
This update corrects a technical issue where bank statements were incorrectly granted elevated permissions. Removing this sudo access enhances security and ensures proper data access controls within the Odoo accounting system. This change improves the overall stability and security of the SaaS platform.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243161 Forward-Port-Of: odoo/odoo#242771
This update resolves an issue where multiple actions on a device weren't consistently recognized. By providing a unique session ID in the response, the system now correctly handles concurrent actions, ensuring users receive confirmation for all initiated tasks. This improves the reliability of device interactions.
Original PR description
Instead of passing `session_id` in the device class parameters, we provide it directly in the response dictionary, in order to allow concurrent actions on the device. Before this commit: - send an action from a PoS: `session_id` is set to `1`, - before the end of the execution, send a second action from the same PoS on the same device (e.g. on another browser): `session_id` is updated to `2`, - you get only one confirmation in the PoS. After this commit: we get both confirmations. Forward-Port-Of: odoo/odoo#243155 Forward-Port-Of: odoo/odoo#243031
This update corrects a display issue where product prices were incorrectly shown as excluding tax, even when tax-included settings were selected in the Point of Sale system. The fix adjusts how prices are calculated to accurately reflect the chosen tax settings, ensuring consistent and correct price displays for users.
Original PR description
Steps to reproduce ------------------ 1. Set the PoS taxes display to tax-included 2. In PoS, add a product, change its quantity to 2, and change its price too Notice that the new price / unit is shown as price excluded, even though we set the prices to tax-included in the PoS settings. Reason ------ We were using the getter `currencyDisplayPriceUnit` which uses `displayPriceUnit` which always shows the price as `tax_exluded`. Fix --- Now we change `displayPriceUnit` to adapt to the `iface_tax_included` config in PoS. That follows well the convention used for the non-unit price getter, `displayPrice`. For the cases where we want to explicitly use the tax excluded unit price, we have created the getters `displayPriceUnitExcl` and `currencyDisplayPriceUnitExcl` for that, which replaces some usages of the old getters. opw-5405572 Forward-Port-Of: odoo/odoo#240091
This update resolves an issue where the price display in the Point of Sale (POS) system was incorrect. The fix replaces a string-based currency display unit with the correct numeric display unit, ensuring accurate price presentation for customers. This improves the overall user experience and prevents potential pricing errors.
Original PR description
We were using `currencyDisplayPriceUnit` inside `Math.sign()`. However, `currencyDisplayPriceUnit` returns a string. Now we use `displayPriceUnit`. opw-5405572 Forward-Port-Of: odoo/enterprise#102160
This update fixes a calculation error related to employee offers for part-time roles. Previously, the system incorrectly attempted to adjust percentages based on full-time salaries. Now, the system accurately reflects the gross salary or employer cost set for part-time offers, streamlining the offer creation process.
Original PR description
When you make an offer to a 4/5 time for example, you set the 4/5 gross or employer cost and not the full, so no need to modify the percentage on the offer Forward-Port-Of: odoo/enterprise#103936
This update fixes a minor issue where search errors were hidden, now consistently displaying a helpful 'Domain is invalid' message. Additionally, the search logic has been optimized for performance and allows users to easily filter for records that don't meet specific criteria (e.g., 'Is Not Set').
Original PR description
Search method logic was rewritten so since commit:
https://github.com/odoo/odoo/commit/92301a5b300dec1ddfca44dc35318b83d67c56fa
`raise NotImplementedError(_("some text"))`
no longer raises an error nor does it ever show the error message. Instead a notification that says "Domain is invalid. Please correct it" is always displayed when the method is unable to run the search. Therefore we update the legacy way of doing it in these search methods so that the code is clean (i.e. so no one copies it) and to avoid translating strings that will never be visible.
Additionally, the search logic was also updated such that the `value` exists is no longer needed and the `=`/`!=` operators are handled by `in` for optimized code. This change makes it so users can now do the "Is Not Set" search since it will return only the records that do not match the "Is Set" logic.
Forward-Port-Of: odoo/enterprise#104115This update corrects a bug where customer statements incorrectly showed zero amounts due in certain reconciliation scenarios. The fix ensures that outstanding balances, including partially reconciled invoices, are accurately reflected in the Customer Statement. This improves the accuracy of financial reporting and customer account management.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874
This update fixes an issue where popups added to product descriptions on the website sale page were appearing behind the product images. The fix ensures popups are always displayed above images, improving the user experience and preventing disruptions when adding information to product details. This change was made to enhance visual clarity and usability.
Original PR description
Steps to reproduce: =================== - Go to website sale & pick any product. - Go to edit mode & drop a popup in the product description -> Popup appear behind of the product image. Cause: ===== Product popups inserted inside the description column (#product_details) inherit it's z-index, while the adjacent .o_wsale_product_images column stays with z-index: 1. Since the details column z-index: 0, any popup inside it remained under the image column. Solution: ========= Override the z-index only when a popup is present opw-5458436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243136
This update ensures that the wizard automatically closes after report downloads, regardless of whether a custom report handler (like for IoT) is used. Previously, using a custom handler caused the wizard to remain open, leading to an inconsistent user experience. This fix maintains the expected behavior of closing the wizard after a report is successfully printed.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#242045 Forward-Port-Of: odoo/odoo#238247
This update corrects a database error that prevented the Tax Report from properly expanding invoice lines. The fix ensures accurate report generation by using the correct table alias to retrieve tax descriptions. New test cases have been added to verify the report's functionality and hierarchical structure.
Original PR description
Before: The `query_tax_lines` method was incorrectly using the account tag alias to access the `description` field, which does not exist on that table. This caused a database error when expanding invoice lines from the Tax Report. After: Now the query correctly uses the `account_tax` table alias to fetch the tax description. - Also added test cases for sales and purchase reports to ensure correct generation of report lines and proper expansion of the hierarchical structure. task-5461512 Forward-Port-Of: odoo/enterprise#103668
This update fixes an issue where tax invoices in Thai were consistently displaying the branch name in English. The change ensures the branch name is now translated based on the language setting of the customer's account, improving accuracy and a better user experience for Thai-speaking clients. This was a minor fix to improve localization.
Original PR description
Currently, l10n_th_branch_name is not translatable. Regardless of the language setting, it is printed in English on the tax invoice. This PR addresses that. Task-5438534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242484
This update corrects a discrepancy in ZATCA invoice XML generation, ensuring accurate line amounts and preventing validation errors. The fix addresses an issue where rounding differences between line items and the overall tax amount were causing ZATCA to reject the invoices. This ensures invoices are correctly formatted for ZATCA submission.
Original PR description
**Steps to reproduce:** * Install the **l10n_sa_edi** and **accounting** modules. * Create a **15% tax** (tax-included). * Create a customer invoice with two lines with amounts 18 and 14 and apply…
**Steps to reproduce:**
* Install the **l10n_sa_edi** and **accounting** modules.
* Create a **15% tax** (tax-included).
* Create a customer invoice with two lines with amounts 18 and 14 and apply
the tax on an invoice line.
* Post the invoice and **send it to ZATCA**.
* Review the generated XML or submit it for ZATCA validation.
**Observed behavior:**
* The XML nodes **LineExtensionAmount**, **TaxAmount**, and
**RoundingAmount** contain inconsistent values.
* ZATCA validation raises warnings due to rounding mismatches.
* Example:
* in xml data look like this
* `15.66(LineExtensionAmount) + 2.34(TaxAmount) != 17.99(RoundingAmount)`(v19)
* The required relation
**LineExtensionAmount + TaxAmount = RoundingAmount**
is violated.
**Cause:**
* In v19.0, `_round_base_lines_tax_details()` distributes rounding deltas so
that the **sum of rounded line taxes** matches the **rounded global tax**.
* When taxes are **included in price** and there are **multiple invoice lines**,
this distribution adjusts the per-line tax and base amounts.
Example pattern:
* Raw line taxes sum to something like **4.1739…**
* Rounded global tax = **4.17**
* Sum of individually-rounded line taxes = **4.18**
* A **-0.01 delta** is distributed across the lines
* Result:
* Line 1 base becomes **15.66**, tax **2.34**
* Line 2 base becomes **12.17**, tax **1.83**
So the XML correctly reports:
* **LineExtensionAmount = 15.66**
* **TaxAmount = 2.34**
* However, **RoundingAmount** is computed differently:
https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L439-L444
* Here, `base_line['tax_details']['total_excluded_currency']` **does not include the distributed delta**. It still reflects the *pre-distribution* base (e.g. **17.99 total excluded**), while **LineExtensionAmount** uses `vals['total_excluded_currency']`, which *does* include the delta.
* Result: the required identity
`LineExtensionAmount + TaxAmount = RoundingAmount`
is broken — producing inconsistencies such as:
`15.66 + 2.34 ≠ 17.99`
**Fix:**
* Use the same **vals[total_excluded_currency]** as it has a tax-excluded price with the delta included.
opw-5402750
Forward-Port-Of: odoo/odoo#240833This update resolves a minor typo within the Odoo Enterprise system. The change ensures the naming of attachment files accurately reflects their associated external IDs and functionality, improving data consistency. This fix prevents potential confusion and ensures proper system operation.
Original PR description
Fix typo – Correct the ir_attachment file name to match the external ID and its functionality. OPW-5428700 Forward-Port-Of: odoo/enterprise#103809
This update fixes an issue where preparation timers for courses within a restaurant order were incorrectly shared. Now, each course has its own dedicated timer, ensuring accurate timing for preparation steps and improving the overall order flow. This enhances the restaurant's operational efficiency and customer experience.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update fixes an issue where the Point of Sale system couldn't reliably find customer records, particularly with demo data. A new setting allows searching both local and server-based customer records, resolving offline test case failures and ensuring accurate customer retrieval.
Original PR description
before this commit: - By default, clicking on a customer only searched local records. - Since the local cache is limited to 100 customers, with demo data it was possible that the required customer was not found. after this commit: - Added 'pressEnter' boolean parameter to search more to also fetch customers from the server. - The boolean parameter was introduced because some test cases require offline mode where fetching from the server would cause issues. runbot-232714, 232715 Forward-Port-Of: odoo/odoo#228786
This update resolves a minor issue with the automated tests for the Helpdesk Live Chat module. The fix ensures the tests run smoothly and reliably, improving the overall stability of the Helpdesk feature. This change focuses on internal testing processes and doesn't impact end-users.
This update resolves an issue where Nilvera e-invoice synchronization was causing conflicts between sales and purchase document updates. By using unique configuration keys based on the transaction type (sale or purchase), the system now ensures that each flow can independently fetch and update invoices without interference, leading to more reliable data synchronization.
Original PR description
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently,…
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently, this parameter is shared between sales and purchase flows, causing their synchronization states to overwrite each other. # Current behavior before PR: When sales and purchase documents are synchronized from Nilvera, both flows use the same configuration parameter to store the last fetched date. As a result, running one synchronization (e.g. sales) may prevent the other flow (e.g. purchases) from fetching new documents, leading to missing or incomplete imports. # Desired behavior after PR is merged: Sales and purchase synchronizations maintain independent last fetched dates by using journal-specific configuration keys. This allows both flows to run reliably and incrementally without interfering with each other. taskId - 5494295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243791
This update resolves an issue where the IoT box was experiencing errors when the Bluetooth adapter wasn't immediately available. The fix ensures the system handles the initial adapter readiness more gracefully, preventing errors and improving the overall stability of the IoT device functionality. This ensures consistent operation of the IoT box.
Original PR description
This PR fixes the bluetooth exceptions seen on the iot box when the bluetooth adapter isn't ready ``` 2026-01-14 10:05:48,596 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in…
This PR fixes the bluetooth exceptions seen on the iot box when the bluetooth adapter isn't ready
```
2026-01-14 10:05:48,596 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in thread Thread-3:
2026-01-14 10:05:48,743 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-01-14 10:05:48,745 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/odoo/.local/lib/python3.13/site-packages/gatt/gatt_linux.py", line 138, in start_discovery
self._adapter.SetDiscoveryFilter(discovery_filter)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
return self._proxy_method(*args, **keywords)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
return self._connection.call_blocking(self._named_service,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
self._object_path,
^^^^^^^^^^^^^^^^^^
...<3 lines>...
args,
^^^^^
**keywords)
^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/connection.py", line 696, in call_blocking
reply_message = self.send_message_with_reply_and_block(
message, timeout)
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: dbus.exceptions.DBusException: org.bluez.Error.NotReady: Resource Not Ready
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger:
During handling of the above exception, another exception occurred:
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
self.run()
~~~~~~~~^^
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/bluetooth_interface_L.py", line 66, in run
dm.start_discovery()
~~~~~~~~~~~~~~~~~~^^
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/odoo/.local/lib/python3.13/site-packages/gatt/gatt_linux.py", line 142, in start_discovery
raise errors.NotReady(
"Bluetooth adapter not ready. "
"Set `is_adapter_powered` to `True` or run 'echo \"power on\" | sudo bluetoothctl'.")
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: gatt.errors.NotReady: Bluetooth adapter not ready. Set `is_adapter_powered` to `True` or run 'echo "power on" | sudo bluetoothctl'.
```This pull request updates the core spreadsheet library used in Odoo. It includes several improvements and bug fixes related to exporting spreadsheets, handling pivot tables, and ensuring accurate cell styling. These changes enhance the spreadsheet functionality and stability.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/52a3e52b0 [REL] 19.1.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/52a3e52b0 [REL] 19.1.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ee24420b9 [IMP] style: rotation xlsx export [Task: 5400633](https://www.odoo.com/odoo/2328/tasks/5400633) https://github.com/odoo/o-spreadsheet/commit/be7c264bd [FIX] style: rotation fix for centered text [Task: 5400633](https://www.odoo.com/odoo/2328/tasks/5400633) https://github.com/odoo/o-spreadsheet/commit/0246149ab [IMP] style: rotation reduce rotation angle precision [Task: 5400633](https://www.odoo.com/odoo/2328/tasks/5400633) https://github.com/odoo/o-spreadsheet/commit/738a1e51a [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782) https://github.com/odoo/o-spreadsheet/commit/8969669e5 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885) https://github.com/odoo/o-spreadsheet/commit/064602de8 [IMP] figure: add data-type attribute to figure carousel tabs [Task: 5447027](https://www.odoo.com/odoo/2328/tasks/5447027) https://github.com/odoo/o-spreadsheet/commit/e8590a8a5 [FIX] Style: UPDATE_CELL overwrites the cell style [Task: 5441149](https://www.odoo.com/odoo/2328/tasks/5441149) https://github.com/odoo/o-spreadsheet/commit/f9b854b76 [FIX] tests: fix network serialization in mock [Task: 5441149](https://www.odoo.com/odoo/2328/tasks/5441149) https://github.com/odoo/o-spreadsheet/commit/418ef27ce [IMP] style: check if default but faster [Task: 5431688](https://www.odoo.com/odoo/2328/tasks/5431688) https://github.com/odoo/o-spreadsheet/commit/f5204e7bd [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a bug preventing internal users from accessing canned responses within the Odoo Portal. The change prepares the Portal for future support of multiple delimiters, correcting a previous misconfiguration and applying a similar fix from another PR. This ensures all Portal users can utilize the composer actions effectively.
Original PR description
*: im_livechat, portal, project, test_mail_full PR #192953 introduces a composer action for canned responses. The feature is available in portal for internal users but since `suggestion` is disabled in portal, this feature doesn't work properly. In preparation for supporting `::` delimiter in portal, the incorrect fix in PR #231360 has been reverted. `inFrontendPortalChatter` is specific to portal frontend and should not be set to `true` in the project sharing environment. Instead of the mentioned fix, a similar fix from PR #231441 has been backported. task-5262349 Forward-Port-Of: odoo/odoo#243686 Forward-Port-Of: odoo/odoo#235551
This update enhances the logging of errors related to Stripe expense processing. Specifically, it now captures full traceback information when errors occur, making it easier to diagnose and resolve issues. Additionally, a fix was implemented to prevent unnecessary actions when a Stripe card is marked for destruction.
Original PR description
## [IMP] hr_expense_stripe: full traceback logging When a pyhon error is raised during a webhook event we only get the error main line, not the full traceback. This adds the full traceback message to the log ## [FIX] hr_expense_stripe: Fix returned card error When a card is returned to the factory for destruction, when Stripe sends us the information, we sent a payload to stripe. This makes no sense as the card has been updated by Stripe into a state that doesn't allow further changes Forward-Port-Of: odoo/enterprise#103940
This update fixes a visual inconsistency in the Odoo Enterprise application. Previously, the subtitle color within the 'Recent' tab was different from other tabs. This change ensures a uniform and professional appearance across all tabs, improving the user experience. This is a minor cosmetic fix.
Original PR description
Since commit [1], the subtitle color has been changed but not for the "Recent" tab, which creates inconsistencies. This commit ensures that the subtitle color is consistent across all tabs. [1]: https://github.com/odoo/enterprise/commit/568d29af1e1d792642f0dc288d57871fc7781f38 task-5485493 | Before | After | |--------|--------| | <img width="800" height="662" alt="Capture d’écran 2026-01-12 à 11 19 34" src="https://github.com/user-attachments/assets/8beb175a-27c8-4d73-899c-6fc3ab22c0e6" /> | <img width="800" height="657" alt="Capture d’écran 2026-01-12 à 11 19 49" src="https://github.com/user-attachments/assets/e2542822-6b05-4b15-b3e8-a4aa7c1b611c" /> | Forward-Port-Of: odoo/enterprise#103996
This update fixes a dashboard issue where employee export data was incomplete, specifically missing employee names and IDs. The changes now display a correct list of employees, and incorporates Prisma code for a better user experience. This ensures accurate reporting of employee data for payroll exports.
Original PR description
\* = {acerta, group_s, prisma}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code.
This commit also adds Prisma code to the external codes group for better UX
task: 5212681
Forward-Port-Of: odoo/enterprise#983896 changes
Resolved issues and error corrections
This update resolves an issue where a payroll rule parameter setup could trigger a system error. The fix ensures that computed fields are always initialized, preventing errors when conditions aren't met. This improves the stability and reliability of payroll calculations.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#102924This update fixes an issue where preparation timers for courses within a restaurant order were incorrectly shared. Now, each course has its own dedicated preparation timer, ensuring accurate timing and a better customer experience. This improves the reliability of order preparation workflows.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update fixes a potential issue where applicants could incorrectly reopen and re-sign expired job offers. The system now prevents access to these offers, ensuring data integrity and a smoother applicant experience. A database constraint has also been added to enforce valid offer durations.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. - Add an SQL constraint on the `validity` field to disallow negative values, ensuring that expired/invalid offers cannot be accessed due to incorrect validity data. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#103734 Forward-Port-Of: odoo/enterprise#101834
This update resolves two issues impacting the Knowledge editor. First, it prevents copy-pasting headings from causing URL redirection problems by resetting unique identifiers. Second, it stabilizes the heading link button by throttling mouse movements, reducing unnecessary page reloads.
Original PR description
### [FIX] knowledge: prevent heading link id duplication on copy/paste Prior to this commit, copy/pasting a heading would preserve its `data-heading-link-id` resulting in mismatches for URL redirections. After this commit, such ids are always reset to guarantee unicity. ### [FIX] knowledge: throttle mousemove for heading link button Prior to this commit, every `mousemove` event could cause a layout trashing to reposition the heading link button. After this commit, the repositioning is debounced at a more reasonable rate. task-5384684
A technical issue preventing users from creating and saving bank statements within the Bank Journal Transactions module has been resolved. The fix addresses a problem where the system couldn't access necessary data, resulting in an error. This ensures users can now correctly create and save bank statements.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277 Forward-Port-Of: odoo/enterprise#101232
Shopee has updated the API paths used for testing their integration with Odoo. This update requires a change to the Odoo testing environment to ensure continued functionality. The team has corrected the API path configuration to align with Shopee’s new requirements.
Original PR description
Shopee has changed the API path and the original testing API paths are no longer valid. Forward-Port-Of: odoo/enterprise#103939
13 changes
Resolved issues and error corrections
This update resolves a migration issue preventing the Odoo 18.3 version from properly updating from 16.0 for Italian businesses. The fix adds a missing column, 'l10n_it_exempt_reason', required during the migration process. This ensures a smooth and successful upgrade for Odoo's Italian localization.
Original PR description
Migration from 16.0 fails because l10n_it_exempt_reason column does not exist Forward-Port-Of: odoo/odoo#240862
This update resolves a technical issue that prevented the creation of payroll rule parameters with future dates, resulting in a system error. The fix ensures that the system correctly handles these parameters, improving the stability and usability of the payroll configuration. This change avoids potential disruptions to payroll processing.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#102924This update fixes a display issue in the restaurant order preparation screen (PDIS) where the first course's timer incorrectly showed 0 until the second course was initiated. Now, each course accurately reflects its preparation time when it's added to the order, ensuring accurate timing for kitchen staff and customers.
Original PR description
Before this commit: -- - In the preparation display (PDIS), the first course shows a preparation time of 0 untill the second course is fired. - After course 2 fired, course 1 and course 2 have same preparation time value. After this commit: -- - Each course shows its correct preparation time when fired. task-5421616 Forward-Port-Of: odoo/odoo#241251
This update corrects an issue where product references were appearing in the names of products displayed on the website's product carousel. This change ensures that product names are clean and accurate, improving the user experience for customers browsing our online store. The fix was triggered by a specific configuration with a single value in a free text attribute.
Original PR description
**Issue**
When a product has a free text attribute with one value, the product reference appears in the name of the product on the product carousel.
**Expected behavior**
The product reference should not appear in the name of the product on the product carousel.
**Steps to reproduce**
1. Create a product to be sold online
2. Give it an internal reference
3. Add a free text attribute with one value
4. Set a product carousel on a website page
5. Disable "show variants" in the settings of the carousel
=> The product reference appears in the name of the product
**Note**
The issue happened only if the free text attribute has only one value, with more than one value, the product reference did not appear.
**Fix**
Updated the QWeb template to use the prepared clean title with data.get('display_name') instead of record.display_name
opw-5410822
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242791This update adds two missing Unit of Measure (UoM) codes – MIN (Minute) and KWH (Kilowatt hour) – to Odoo, aligning with UNECE Recommendation No. 20 for Peppol. This ensures proper support for UBL/CII electronic invoices, resolving an issue where the default 'Units' code was used instead, and addresses a need identified by localization modules.
Original PR description
**Issue:** 2 UoM that is in the UNECE Recommendation No.20 for Peppol don't exist in Odoo: - MIN: Minute - KWH: Kilowatt hour Even if they are created manually, they are not used in the UBL/CII electronic invoices. Instead, the default code (i.e. "C62" for "Units" is used). Some localization modules create the "Kilowatt hour" UoM as they need it. (l10n_cl and l10n_tr_nilvera) So it's better to have a "generic" one available for every module. opw-5269119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243535 Forward-Port-Of: odoo/odoo#238342
This update fixes a validation error that occurred when creating partial backorders within wave transfers. The issue stemmed from the system incorrectly identifying an active batch as a candidate for new backorders, leading to a user error. This change ensures that the current batch is excluded during the auto-batch process, resolving the validation conflict.
Original PR description
## How to reproduce: - Enable Wave transfert in setting - Go to the Receipt Operation type: - Create Backorder: always - Automatic Batches: Enabled - Wave Grouping: Products - Create and confirm…
## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
- Create Backorder: always
- Automatic Batches: Enabled
- Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."
## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.
## Solution:
Exclude the current wave/batch from the auto_wave search domain using a context variable passed during validation.
OPW-5413921
---
Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ...
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ======================================================================
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
wave.action_done()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
return pickings.with_context(**context).button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
res = super().button_validate()
^^^^^^^^^^^^^^^^^^^^^^^^^
...
File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
records.write({self.name: write_value})
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
self.batch_id._sanity_check()
File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243519This update corrects a bug where clicking 'Back' in the cart sometimes caused unexpected product additions. The fix clarifies the trigger used to add products, preventing duplicate actions and ensuring consistent cart behavior. This improves the overall user experience and reduces potential errors during checkout.
Original PR description
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ... With the following scenario, step CartPage.clickBack() can take few…
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ...
With the following scenario, step CartPage.clickBack() can take few times to show the back screen, but as the trigger is the same for clickProduct on a product list screen than a cart screen, the last step clik on "o_self_product_box" ... but in the cart (and not in the product list)
ProductPage.clickProduct("Coca-Cola"), => OK
ProductPage.clickProduct("Coca-Cola"), => OK
Utils.clickBtn("Checkout"), => OK
CartPage.checkProduct("Coca-Cola", "5.06", "2"), => OK CartPage.clickBack(), => OK
ProductPage.clickProduct("Coca-Cola"), => NOK
To fix it, it is enought to just be more precise on the trigger to avoid confusions.
This fix fixes probably a pair of tours.
error-runbot-id~227669
(and probably others)
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-prThis update fixes an issue where the DDT number was missing from delivery confirmation reports for Italian companies. The change ensures the DDT number is generated and included before the email is sent, resolving a reporting discrepancy. This improves the accuracy and completeness of delivery documentation.
Original PR description
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending…
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265 Forward-Port-Of: odoo/odoo#243492
This update automatically corrects discrepancies between check amounts and payment amounts when using third-party checks for vendor payments. Previously, users had to manually adjust payment amounts, leading to errors and delays. This change ensures accurate payment processing and eliminates manual intervention.
Original PR description
Current behavior: when using third-party checks to create vendor payments, withholding amounts are creating a difference between the checks amount and the payment amount, resulting in a warning and requiring manual adjustment of the payment amount until the amount minus withholdings matches checks amount. Solution: adding an automated adjustment algorithm to the wizard. task-4257629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219922
This update resolves an issue where group chat channels (group DMs) were displaying incorrect status information, leading to confusing user experiences like a 'back on' banner and incorrect IM status. The fix removes a calculation that caused this behavior, ensuring group DMs display their status accurately.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#243628 Forward-Port-Of: odoo/odoo#242058
This update resolves an issue where users were blocked from settling customer balances in Point of Sale when ZATCA integration was active. The fix removes the forced invoice requirement for settlement orders, allowing users to complete payments without generating duplicate e-invoices to ZATCA.
Original PR description
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale…
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled. ## Current behavior before PR: When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA. However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because: - Settlement orders do not contain any lines, so a new invoice cannot be generated. - The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice. Thus, the user cannot proceed with the settlement. ## Desired behavior after PR is merged: After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243604 Forward-Port-Of: odoo/odoo#233769
This update resolves an issue where a Point of Sale order incorrectly remained flagged as a 'settlement' after a user canceled a payment attempt. By resetting the order flag, this prevents incorrect processing and ensures compliance with integration rules. This improves order accuracy and avoids potential errors.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. task-id - 5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#104197 Forward-Port-Of: odoo/enterprise#98463
This update fixes a reporting issue related to Bebat, a Belgian organization recycling batteries. It ensures that recycling taxes are correctly identified as 'Special Agreement' (64) or 'Battery Collection and Recycling' (CAV) instead of the previous 'New Outlet Discount' (66) or 'Collection and recycling' (AEO) classifications, aligning with regulatory requirements.
Original PR description
[FIX] account_edi_ubl_cii: EPD allowance/charge code should be 64, not 66 64 stands for "Special agreement" 66 stands for "New outlet discount" opw-5478324 [FIX] account_edi_ubl_cii: Bebat allowanceChargeReasonCode should be CAV Bebat is a non-profit organization in Belgium that collects, sorts, and recycles used batteries. Currently, whatever the recycling tax applied, we report is as AEO for "Collection and recycling - The service of collection and recycling products." However, since Bebat is about recycling batteries, we have to use CAV instead for "Battery collection and recycling - The service of collecting and recycling batteries." opw-5474752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243064
2 changes
Resolved issues and error corrections
This update addresses a technical issue related to how Odoo handles deleted records, specifically those linked to emails and activities. The change ensures that Odoo doesn't unnecessarily query related records after a cascade delete, improving performance and stability. This is a critical fix to prevent potential slowdowns.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104095 Forward-Port-Of: odoo/enterprise#101185
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing documents sent from records they couldn't access. The system now verifies read access to the related record before redirecting, ensuring a smoother sign-off experience for all users.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#100961
18 changes
Resolved issues and error corrections
This update fixes an issue where preparation timers for courses within a split order were incorrectly shared. Now, each preparation order has its own timer, ensuring accurate timing for each course and improving the restaurant's order fulfillment process. This change enhances the overall customer experience.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update ensures that archived employees are no longer included in payroll runs and pay slip forms. This prevents incorrect payments and simplifies payroll processing by focusing only on active employees. The changes remove outdated filters and improve data accuracy.
This update resolves a technical issue that caused a traceback error when removing a selected pay category for employees in the payroll section. The fix ensures the system handles the removal of pay category selections correctly, preventing errors and improving payroll stability. This change impacts the HR Payroll module.
Original PR description
Fixed a traceback bug that appears when removing unselecting the Pay Category in the Employee's form payroll tab Steps to reproduce: - Select a pay category for an employee - Delete your selection - Traceback appears Cause: _compute_display_be checks on the name of the structure_type_id without checking that this field is not null, producing a bug when its value is removed task-5453432
This update fixes a minor issue in the Thai tax reporting module where trailing spaces were causing incorrect calculations in tax reports. The change removes this space, restoring the reports to accurately reflect tax liabilities. This ensures data integrity for Thai businesses using Odoo Enterprise.
Original PR description
-Report line formula was converted from Char to Text, which no longer strips trailing spaces. -The fix removes the trailing space from "formula" to restore correct behavior. Related Community PR: https://github.com/odoo/odoo/pull/242462 task-5468804
This update corrects a database error that prevented the Tax Report from properly expanding invoice lines. The fix ensures accurate report generation by using the correct database table for tax descriptions. New test cases have been added to verify the report's functionality.
Original PR description
Before: The `query_tax_lines` method was incorrectly using the account tag alias to access the `description` field, which does not exist on that table. This caused a database error when expanding invoice lines from the Tax Report. After: Now the query correctly uses the `account_tax` table alias to fetch the tax description. - Also added test cases for sales and purchase reports to ensure correct generation of report lines and proper expansion of the hierarchical structure. task-5461512 Forward-Port-Of: odoo/enterprise#104111 Forward-Port-Of: odoo/enterprise#103668
This update fixes a technical issue preventing AI server tools from running correctly. The problem stemmed from an unnecessary inclusion of '__end_message' in tool arguments, causing validation errors. The fix ensures correct tool execution by removing this element before validation.
Original PR description
When executing AI server actions, tools with `ai_tool_schema` defined would fail with "Missing definition for __end_message" error. Root cause: - `_prepare_tools` adds `__end_message` to the schema sent to the LLM - The LLM returns tool calls with `__end_message` in arguments - `_ai_tool_run` validates arguments against the original schema (which doesn't have `__end_message`) - Validation fails with "Missing definition for __end_message" Fix: Use `pop` instead of `get` to extract and remove `__end_message` from arguments before calling the tool executor. This ensures that it's not passed to the tool validation. TASK-ID: 5423756 Forward-Port-Of: odoo/enterprise#103779
This update fixes an issue where the 'Out of Contract' calculation was incorrectly extending beyond the payslip period. The change ensures that contract overlap dates are accurately limited to the payslip's start and end dates, preventing inaccurate payroll reporting. This improves the reliability of employee compensation data.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#103539 Forward-Port-Of: odoo/enterprise#100694
This update enhances the logging of errors related to Stripe expense transactions. Specifically, it now captures full traceback information when errors occur during webhook events, providing more detailed insights for troubleshooting. Additionally, a fix was implemented to prevent unnecessary actions when a Stripe card is marked for destruction, ensuring data integrity.
Original PR description
## [IMP] hr_expense_stripe: full traceback logging When a pyhon error is raised during a webhook event we only get the error main line, not the full traceback. This adds the full traceback message to the log ## [FIX] hr_expense_stripe: Fix returned card error When a card is returned to the factory for destruction, when Stripe sends us the information, we sent a payload to stripe. This makes no sense as the card has been updated by Stripe into a state that doesn't allow further changes Forward-Port-Of: odoo/enterprise#103940
This update fixes a dashboard display issue that previously showed incomplete employee information during payroll exports. The changes now correctly list employees without version ID export codes and incorporate Prisma code for a better user experience. This ensures accurate and complete payroll export data.
Original PR description
\* = {acerta, group_s, prisma}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code.
This commit also adds Prisma code to the external codes group for better UX
task: 5212681
Forward-Port-Of: odoo/enterprise#98389This update fixes a random failure in a key tour that simulates unpacking packages onto pallets within the stock management system. The issue stemmed from a timing conflict during the tour's steps, leading to incomplete actions. The fix adds a verification step to ensure the first pallet line is fully unpacked before proceeding, improving the tour's reliability.
Original PR description
Before this commit, the tour `test_internal_picking_reserved_move_packages_into_new_palet` was randomly failing. In this tour, we have two palets we unpack. The issue is, after unpacked the first one, we complete the second one line and then we unpack it. But it can happen the click on the button to complete the second line was done too quickly (in the meantime the first palet line is unpacked) and thus, because of this race condition, the second palet line was not complete (either it's just a visual bug due to a refresh in the wrong time, either the complete action is dropped due to the first line unpacking action.) To fix that, this commit adds a step to verify the first line is correctly unpacked before going further. runbot-build-error: [237801](https://runbot.odoo.com/odoo/runbot.build.error/237801) Forward-Port-Of: odoo/enterprise#104261
This update resolves a technical error that occurred when a sale order lacked an invoice date. The fix ensures that stock move filters now correctly use either the order's last invoice date or today's date, preventing a traceback and ensuring accurate stock management for subscription orders. This improves the reliability of the subscription order fulfillment process.
Original PR description
The Issue: Prior to this commit, When the sale order last_invoice_date is False, a traceback is thrown The Fix: To resolve this, We get the last_invoice_date or todays date opw-4403557 Forward-Port-Of: odoo/enterprise#75717
This update resolves an issue where wage calculations were producing incorrect results and causing validation errors when changing working schedules. The changes improve the accuracy of hourly wage calculations by dynamically determining working hours from company calendars and removing unnecessary dependencies, leading to a more stable and reliable payroll system.
Original PR description
- All percentage fields now use self.env.remove_to_compute to break circular dependencies, so UIs no longer need the ad-hoc skip_percentage_calc context. - _l10n_in_get_montly_wage now derives monthly hours from the version’s or its company’s resource calendar via hours/week previously it was static to 22 days. - fix raises validation when opening offer after changing working schedule it raise validation error which isn't expected behaviour. task-5421228 Forward-Port-Of: odoo/enterprise#103889 Forward-Port-Of: odoo/enterprise#102488
This update fixes a bug where document favoriting wasn't working correctly, particularly when multiple documents were involved. The change ensures consistent behavior for toggling favorites, even with different user permissions, and adapts the process for batch operations. This improves the overall user experience for managing document favorites.
Original PR description
The inverse method for the computed field was actually implementing a toggle instead of writing the passed value. We modify it and update the existing test to not only check the compute method but…
The inverse method for the computed field was actually implementing a toggle instead of writing the passed value. We modify it and update the existing test to not only check the compute method but also the inverse method.
Note that this behavior is currently used in
documents/static/src/views/kanban/documents_kanban_renderer.js (useCommand, Toggle favorite that writes on the selection the opposite of is_favorited of the first record on the whole selection).
[IMP] documents{_spreadsheet}: adapt toggle favorite for batch of records
We update the document toggle_favorited method to work in batch with the following logic: if all documents share the same state (either all favorited or all not favorited), the method toggles their state; otherwise, it marks all items as favorites. Then using that updated method, we improve the toggle favorite method of the document service to support multiple documents and manage the reload.
We also apply the correction of the shortcut command for favorite introduced in odoo/enterprise#89928 but not propagated to master. That correction ensures we use the toggle_favorited method rather than writing on the is_favorited field, so that it also works in all situation (even if the user doesn't have write permission on the document).
Partially based on the forward port of odoo/enterprise#89928 (by adsh-odoo).
Task-5095066This update fixes an issue where the quantity of products scanned via GS1 barcodes wasn't correctly reflected in manufacturing orders. Previously, the system only added one unit regardless of the barcode's specified quantity. Now, the system accurately uses the barcode's quantity to update the finished product's output, ensuring consistency and accurate tracking of manufactured goods.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#104240 Forward-Port-Of: odoo/enterprise#95174
This update fixes an issue preventing non-administrator users from updating GI CFDI sequences. Previously, the system required elevated privileges, limiting functionality. Now, sequence updates are available to all users, streamlining the process for generating CFDI documents.
Original PR description
In odoo/enterprise#102500, support was added for custom GI CFDI sequences at branch level. However, the sequence consumption fails for non-admin users due to missing write access on ir.sequence, so sudo() is required when updating number_next. Forward-Port-Of: odoo/enterprise#104242
This update corrects a calculation error in part-time contracts. Previously, the system incorrectly attempted to adjust percentages when a 4/5 or part-time offer was created, leading to inaccurate salary calculations. This fix ensures that offer percentages are automatically determined based on the specified part-time rate.
Original PR description
When you make an offer to a 4/5 time for example, you set the 4/5 gross or employer cost and not the full, so no need to modify the percentage on the offer Forward-Port-Of: odoo/enterprise#104294 Forward-Port-Of: odoo/enterprise#103936
This update resolves an issue related to the DmfA declaration in the Belgian payroll module. The change adapts the payroll calculations to align with recent refactoring efforts within the Odoo Enterprise platform. This ensures accurate and compliant payroll processing for Belgian employees.
Original PR description
Forward-Port-Of: odoo/enterprise#104175
This update hides the 'suggest next documents' tab within the signing feature from users who are not logged into Odoo. This change ensures that sensitive document suggestions are only visible to authorized personnel, enhancing security and data protection. It aligns with our security protocols for confidential document workflows.
Original PR description
This commit makes the suggestion tab of signing next documents hidden to public users, as they should be logged in to be able to see the next documents to be signed. task-5487349 Forward-Port-Of: odoo/enterprise#104287
10 changes
Resolved issues and error corrections
This update fixes an issue where preparation timers for courses in a restaurant order were incorrectly shared. Now, each course has its own dedicated preparation timer, ensuring accurate timing for each stage of the order. This enhances the restaurant's order fulfillment process and improves customer experience.
Original PR description
Before this commit: -- - When an order was split into courses, all preparation orders incorrectly shared the same timer, even if fired at different times. After this commit: -- - Each preparation order has its own preparation timer when its course is fired. task-5421616 Forward-Port-Of: odoo/enterprise#102845
This update resolves an issue where a specific configuration in the payroll rule parameters could trigger an error. The fix ensures that computed fields are correctly initialized, even when conditions related to future dates are not met. This prevents a traceback and maintains the stability of payroll calculations.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#102924This update resolves a technical issue where location IDs could incorrectly identify related locations, leading to test failures. Replacing `includes` with `indexOf` ensures accurate sublocation detection, improving the reliability of the stock barcode functionality. This fix addresses a build error and prevents potential disruptions in the system.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292)
A recent update to the 'account_no_followup' module caused a memory error during installation on older Odoo versions. This fix avoids a large data calculation that was overwhelming the system's memory. The change ensures smoother installations and prevents potential performance issues.
Original PR description
The module `account_no_followup` is a new module added in odoo/enterprise#96627. Since it's marked as `auto-install=True` and since it's a dependency of the new `pos_no_followup` module, it may be installed on existing 18.0 databases with a lot of account.move.lines. In this case, the module installation will raise a MemoryError as there's a new stored computed field on journal items called `no_followup`. Computing this field and storing the value in cache will overfill `self.env._cache` and reach the 2GB threshold. This commit fixes that by adding an overwrite of the `_auto_init` method to initialize the field's value in raw SQL, circumventing the issue. Forward-Port-Of: odoo/enterprise#102330
This update fixes a previous error that occurred when users deleted the 'Balance' line in the General Ledger Report. The fix prevents the report from crashing and ensures it functions correctly, even when balance information is removed. This improves the user experience and report reliability.
Original PR description
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting >…
Currently an error is generated when the user deletes the `Balance` line of `Column` tab from the General Ledger Report as in the below steps: - Install accountant with demo data - Go to Accounting > Configuration > Accounting (section) > Accounting Reports - Open the General Ledger report - Delete the balance line from the Column tab - Go to Reporting > General ledger >> Error occurs (If an error does not occur, try opening the detailed view of the journal in the report.) Error: `KeyError: 'balance'` This issue was generated because at code line [1] tries to access `balance` key from the `colname_to_idx[col_group_key]` but since the user deleted `balance` it will not fount there and we got an error. This commit fixes the issue by preventing the processing of `line_balance` when the balance key is not present in `colname_to_idx[col_group_key]`. [1]: https://github.com/odoo/enterprise/blob/340abdc1b00df4d3d6130b26650519ae8354d199/account_reports/models/account_general_ledger.py#L326 sentry-7105657812 Forward-Port-Of: odoo/enterprise#102113
This update corrects a visual inconsistency within the Odoo Enterprise VoIP module. Previously, the subtitle color in the 'Recent' tab differed from other tabs. This commit ensures all tab subtitles have the same color, improving the overall user experience and maintaining a consistent design.
Original PR description
Since commit [1], the subtitle color has been changed but not for the "Recent" tab, which creates inconsistencies. This commit ensures that the subtitle color is consistent across all tabs. [1]: https://github.com/odoo/enterprise/commit/568d29af1e1d792642f0dc288d57871fc7781f38 task-5485493 | Before | After | |--------|--------| | <img width="800" height="662" alt="Capture d’écran 2026-01-12 à 11 19 34" src="https://github.com/user-attachments/assets/8beb175a-27c8-4d73-899c-6fc3ab22c0e6" /> | <img width="800" height="657" alt="Capture d’écran 2026-01-12 à 11 19 49" src="https://github.com/user-attachments/assets/e2542822-6b05-4b15-b3e8-a4aa7c1b611c" /> | Forward-Port-Of: odoo/enterprise#103996
This update resolves a technical issue preventing users from creating and saving bank statements within the Bank Journal Transactions section. The problem stemmed from an error in how data was accessed, which caused a system crash. This fix ensures stable bank statement functionality.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277 Forward-Port-Of: odoo/enterprise#101232
This update resolves a display problem in the General Ledger report when using analytic accounting. Previously, the report incorrectly showed duplicate lines and linked to the wrong journal entries. The fix ensures accurate grouping by analytic accounts, directing users to the correct journal entries.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#104082 Forward-Port-Of: odoo/enterprise#103169
This update ensures that historical survey answers retain their original date and datetime formatting, even if the question type is changed afterward. Previously, modifying a question type could cause formatting errors in exported spreadsheets. This change improves data consistency and reliability for survey results.
Original PR description
Current behavior before PR: - Survey spreadsheet export derived date and datetime formatting from the current question type. - Changing a question type after submission (date to datetime) could lead to incorrect formatting or export errors for existing answers. Desired behavior after PR is merged: - Spreadsheet export now derives value conversion and formatting from the stored answer type instead of the question definition. - Historical answers keep their original date or datetime format, even if the question type is modified later. Task: [5410758](https://www.odoo.com/odoo/project/2328/tasks/5410758)
This update resolves a technical issue that caused a traceback error when using pivot tables in the spreadsheet feature. The fix ensures pivot tables function correctly, even when certain data dimensions are missing, improving the reliability of reporting and analysis. This impacts users who rely on spreadsheet-based reporting.
Original PR description
Task: 5085724
15 changes
Resolved issues and error corrections
This update corrects a problem that prevented the migration of Odoo from version 16.0 to 18.0 for the Italian accounting module (l10n_it). The fix adds a necessary column to the database, resolving the migration failure. This ensures a smooth upgrade process for Italian businesses using Odoo.
Original PR description
Migration from 16.0 fails because l10n_it_exempt_reason column does not exist Forward-Port-Of: odoo/odoo#240862
This update ensures that pressing the mobile back button closes the chat window, mirroring the functionality of the 'X' button. Previously, the back button caused unexpected navigation. This improves the mobile chat experience and prevents users from losing their place within conversations.
Original PR description
**Current behavior before PR:** - The back button on mobile does not close the open chat window. - Pressing it navigates away from the page instead of closing the chat window. - Only the "X" button can be used to exit a chat. **Desired behavior after PR is merged:** - Pressing the mobile back button will now behave the same as clicking the "X" button. - It will close the current chat window and prevents unwanted navigation in browser history. task-[4563827](https://www.odoo.com/odoo/project/1519/tasks/4563827) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where only the first attachment from an expense was included in the generated journal entry. The change ensures that all attachments associated with approved expenses are now correctly copied, improving the accuracy and completeness of financial records. This prevents data loss and provides a more reliable view of expense details.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#241044
This update ensures that the DDT number is correctly included in the delivery reports sent to customers. Previously, the number was missing because it was generated after the email was sent. This fix resolves a reporting issue, improving the accuracy and completeness of delivery confirmations for Italian businesses using the l10n_it_stock_ddt module.
Original PR description
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending…
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265 Forward-Port-Of: odoo/odoo#243492
This update resolves an issue where pivot tables in the spreadsheet module weren't correctly calculating data. By adding a key to the pivot registry, the system now accurately re-evaluates pivot data, ensuring correct and reliable reporting. This improves the overall accuracy and usability of the spreadsheet feature.
Original PR description
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 provides users with more detailed error messages when sending documents to HMRC. By including the specific error code and message from HMRC, users can quickly understand and resolve issues, reducing the need for support. This enhancement improves the user experience and streamlines the document submission process.
Original PR description
Currently, when an error occurs while sending a document to HMRC, the user only receives a generic error message. This change enhances the error feedback by including the error code and message returned by HMRC, giving the user clearer insight into the cause of the failure. This helps users identify issues more easily and reduces unnecessary support requests.
This update fixes a bug where inviter notifications were sent to portal users when they connected for the first time, causing unnecessary alerts. Now, inviter notifications are only triggered for internal users, streamlining the process and improving the user experience. The notification message has also been updated for clarity.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited…
**Description of the issue this PR addresses:** ------------------------------------------------ When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users. For portal users, this resulted in unnecessary toast notifications and chat window pop-ups. **Current behavior before PR:** --------------------------------- - The inviter is notified when any invited user connects for the first time. - This includes portal users. - Unnecessary notifications and chat pop-ups are shown for portal user connections. **Desired behavior after PR is merged:** ----------------------------------------- - The inviter is notified **only when an internal user** connects for the first time. - Portal users no longer trigger first-connection notifications. - The notification message is updated to: “[Username] just connected for the first time. Wish them luck!” **Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where discoverable subfolders accessed via sharing links weren't initially displayed correctly. The fix sends a flag to refresh the document access when a new folder is loaded, ensuring subfolders are immediately visible to users. This improves the user experience when sharing documents.
Original PR description
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) -…
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) - Copy the share link - Login with the portal user in an incognito window - Paste the share link in an incognito browser - Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture - Click on "brand 2" - Click back on "brand 1" and now the folder and picture are visible - If you click on a subfolder of "brand 1" you also get an error **Issue:** Discoverable subfolders accessed using `accessToken` are not available on the first read of a user and this happens for each level of the hierarchy (refresh is needed each time). When using sharing link to display folders with a user, the subfolder document access is created on `/documents/touch/` using `_from_access_token`. But on the js side the call is delayed (with debounce) and occurs after the `web_search_read`. This means that subfolders are only accessible after a refresh or by switching back and forth between folders. Also, even after the folder is displayed, if there are other subfolders in it, going deeper in the hierarchy won't work as well without a refresh due to the `search_panel_select_range` missing the new folder. **Fix:** Not sure on the best way to fix this, the issue will always be related to performance. Current fix checks if a reload is needed by sending a flag in the `/documents/touch/<access_token>` request result when a new document access was created. opw-5156297
This update resolves a potential error that could occur in the accounting system when all possible distribution factors are zero. The change ensures the system handles this specific scenario correctly, preventing a traceback and maintaining accurate accounting calculations. This improves system stability and reliability.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none
This update fixes an issue where the quantity delivered on sale orders wasn't accurately updated after a partial refund with a 'Ship Later' option. The fix ensures that the delivered quantity reflects the actual items remaining after the refund is processed, improving order accuracy and reporting. This resolves a discrepancy in how the system tracks inventory following a partial refund.
Original PR description
The qty_delivered on sale.order.line was not correctly computed when the original order was refunded with a ship later. Steps to reproduce: ------------------- * Create a sale order for 5 quantities of any product * Confirm the sale order * Settle the order in the PoS * At this point the qty_delivered on the sale order line is 5 * Now go back to the PoS and refund partially the order for 3 quantities and use the "Ship Later" option > Observation: The qty_delivered is 0 instead of 2 Why the fix: ------------ We group the pos.order.line by procurement group and then check if all pickings related to these lines are done before adding the qty to the qty_delivered. We also make sure to include the refund lines in the computation opw-5059560
This pull request enhances message access and search functionality within Odoo by ensuring consistency across read, search, and portal user experiences. Specifically, it addresses issues with document-level access checks, symmetric search results, and portal user domain application, ultimately improving data accuracy and usability.
Original PR description
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need…
Message access is notably based on related document, given their (model, res_id) pair. Model may customize the required access on it in order to access their message. For example, you generally need write access to create a message (post) but on some models you can post when you can read. Calendar events message access depends on calendar privacy settings. This is controlled via '_get_mail_message_access'. However currently it is "globally called", for all documents. It should be done on a per-document basis, as each document could define different access check. Keep code somewhat optimized by doing access checks in batch for a given operation. Make _search and read symmetric. Reading documents should be allowed on search results, and search results should match what is available for reading. Portal users have some specific domains applied when accessing messages, see notably odoo/odoo@9cd9aaaa174ae1f2a0af12143a34eb4682ea6f59 (but also check for 'website_message_ids' domain, mail controllers, ...). However there are still some cases where search and read are not coherent with portal users. This is not really annoying as most messages are accessed using sudo and correctly tailored domains via controllers but let us try to have a more correct code. Fix discuss support of post check capabilities * not taking into account '_get_mail_message_access' to check if user has right to post (generally used to indicate users can post on readonly records, but not limited to that) in 'readonly' computation in frontend and in controllers; * not adding the same check on Activities button as on Send message and Log note. We consider generally that rights should be aligned and UX should match that behavior; * not adding the same check on attachments buttons, currently limited to write access (or always accessible). This is a preliminary work for attachments, further fixes are probably incoming; Mainly a backport of master improvement done at https://github.com/odoo/odoo/pull/214705 . Task-5138368 opw-4785878 Forward-Port-Of: odoo/odoo#233725
This update ensures that EDI identification details used during registration are consistently synchronized across systems, particularly for Peppol integrations. Previously, provided identification numbers could be outdated, leading to potential registration issues. This fix improves data accuracy and reliability for Peppol-related processes.
Original PR description
We introduced for Peppol the possibility to deduce an identification from another one therefore, the provided edi_identification at registration can sometimes not be the one that is actually used when registering to the AP. This commit adds ways to synchronize it to keep it consistent. See https://github.com/odoo/iap-apps/pull/1334 task-none
This update enhances the Point of Sale system by introducing a background queue for 'isUnsyncedPaid' orders. This prevents slowdowns and errors when many orders are being processed simultaneously, ensuring reliable and efficient order synchronization. The system now handles errors gracefully, retrying failed orders to maintain data accuracy.
Original PR description
Implement a background queue system to handle isUnsyncedPaid orders separately from regular order synchronization. This prevents issues when multiple pending orders are being synced simultaneously. Orders are now categorized into three types: - Orders from options.orders: sync normally with await - Non-isUnsyncedPaid pending orders: sync normally - isUnsyncedPaid orders: process sequentially through background queue The queue processing pauses during explicit sync operations and resumes automatically afterward. This prevents race conditions and ensures orders are synced reliably one-by-one. Error handling differentiates between error types: - RPCError: removes order from queue and shows user notification - ConnectionLostError: pauses queue and keeps order at front for retry - Timeout/other errors: moves order to end of queue for retry opw-5111772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where calendar events synced to Outlook would sometimes create duplicate events in both Odoo and Outlook due to network delays. The fix ensures that Odoo correctly links events created with Microsoft after a timeout, preventing these duplicates from occurring.
Original PR description
When creating an event in Odoo that syncs to Outlook, a timeout or network error during the response from Microsoft can leave the system in an inconsistent state, leading to duplicate events in both…
When creating an event in Odoo that syncs to Outlook, a timeout or network error during the response from Microsoft can leave the system in an inconsistent state, leading to duplicate events in both Odoo and Outlook during subsequent synchronizations.
### Steps to reproduce
1. Create a calendar event in Odoo with Outlook synchronization enabled.
2. Simulate a network timeout (currently set to `3 seconds`) after Microsoft processes the creation request but before Odoo receives the response (e.g., by mocking a timeout in `_microsoft_insert`).
3. Observe that the event exists in Outlook but the Odoo record lacks the `microsoft_id`.
4. Run the synchronization manually.
5. A duplicate event is created in Outlook (due to retry) and/or a duplicate event is created in Odoo (fetched from Outlook as "new").
### Root Cause
The synchronization logic in
`microsoft_calendar/models/microsoft_sync.py` relies on receiving a successful response from the Microsoft Graph API to link the Odoo record with the created Outlook event.
Specifically, in the `_microsoft_insert` method, the call to `microsoft_service.insert` sends the creation request. If Microsoft successfully processes this request and creates the event, but the network connection times out while waiting for the response, the subsequent line `self.write({'microsoft_id': event_id, ...})` is never executed.
At this point, the Odoo record remains with `microsoft_id=False` and `need_sync_m=True`, even though the event actually exists in Outlook.
During the next synchronization:
1. `_sync_odoo2microsoft` identifies the Odoo record as unsynced (`microsoft_id=False`) and sends a new insertion request, creating a second event in Outlook.
2. `_sync_microsoft2odoo` fetches the original event from Outlook. To match Outlook events back to Odoo records, the logic in `MicrosoftEvent._load_odoo_ids_from_db` searches for Odoo records having a matching `microsoft_id` or `ms_universal_event_id` (a global ID provided by Microsoft). Since the Odoo record was never updated with these IDs, the match fails. Odoo treats the incoming event as a new external item and creates a duplicate record in Odoo.
### Fix Rationale
To resolve this, we utilize the `transactionId` property of the Microsoft Event resource. The `transactionId` is an optional, client-provided string that Odoo can attach to an event during creation. This ID is stored by Microsoft and remains accessible in the event's properties, allowing the client to identify the event independently of the server-generated IDs.
1. We now generate a deterministic `transactionId` for each insertion using the format `<database.uuid>_<record.id>`. This ID is unique to the Odoo record and remains stable across synchronization retries.
2. This `transactionId` is included in the payload of the event creation request within the `_microsoft_values` method of the `calendar.event` and `calendar.recurrence` models.
3. The matching logic in `MicrosoftEvent._load_odoo_ids_from_db` is extended with a fallback mechanism. If an incoming Outlook event cannot be matched by its server-generated IDs, the code checks for a `transactionId`. If the `transactionId` matches the current database UUID and contains a valid Odoo record ID, Odoo identifies the record it originally intended to create and links them.
This ensures that if an insertion response was previously lost due to a timeout, Odoo can still find and link the existing Outlook event during the next synchronization instead of creating a duplicate.
opw-5031073This update enhances the reliability of point-of-sale order synchronization by introducing a background queue for 'isUnsyncedPaid' orders. This prevents slowdowns and errors when multiple orders are being processed simultaneously, ensuring orders are synced reliably. The system also includes robust error handling for various issues, improving overall order processing stability.
Original PR description
Implement a background queue system to handle isUnsyncedPaid orders separately from regular order synchronization. This prevents issues when multiple pending orders are being synced simultaneously. Orders are now categorized into three types: - Orders from options.orders: sync normally with await - Non-isUnsyncedPaid pending orders: sync normally - isUnsyncedPaid orders: process sequentially through background queue The queue processing pauses during explicit sync operations and resumes automatically afterward. This prevents race conditions and ensures orders are synced reliably one-by-one. Error handling differentiates between error types: - RPCError: removes order from queue and shows user notification - ConnectionLostError: pauses queue and keeps order at front for retry - Timeout/other errors: moves order to end of queue for retry related pr: https://github.com/odoo/odoo/pull/230815 opw-5111772
9 changes
Resolved issues and error corrections
A bug was found in the Dutch Profit & Loss report where Cost of Goods Sold and Cost of Sales codes were incorrectly linked. This resulted in inaccurate financial reporting. This update corrects the code mapping to ensure proper financial data is displayed.
Original PR description
**Steps to reproduce:** 1. Install l10n_nl_report. 2. Go to Accounting → Configuration → Accounting Reports. 3. Open Profit and loss report (tags). 4. Click on Cost of Goods Sold or Cost of Sales and check the related codes. **Issue:** In the Dutch Profit and Loss report, the codes assigned to the "Cost of Goods Sold" and "Cost of Sales" line items are swapped. Currently: - Cost of Goods Sold is linked to code: NL_SALE - Cost of Sales is linked to code: NL_COGS This results in incorrect mapping and misleading financial reporting. **Cause:** The codes were incorrectly applied, leading to reversed definitions between Cost of Goods Sold and Cost of Sales. See: https://www.investopedia.com/terms/c/cogs.asp Solution: Swap the code values so that: - NL_COGS → Cost of goods sold - NL_SALE → Cost of sales
This update fixes an issue where users couldn't manage their consent for online account synchronization. The change introduces a message to the account synchronization link, allowing users to control their data sharing preferences. The update also enhances the system's flexibility by using provider type to support various synchronization providers.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621
This update corrects a bug where loyalty points weren't accurately calculated when re-loading saved Point of Sale (PoS) orders. Previously, points weren't correctly applied after saving and reloading an order, leading to incorrect point totals. This fix ensures accurate point calculations for loyalty programs when orders are reloaded.
Original PR description
When an order was saved then reloaded in the PoS, the points awarded for a loyalty program were not computed correctly. Steps to reproduce: ------------------- * Create a loyalty program that gives one point for every € spent * Activate the trusted pos option in the PoS settings * Open a PoS session and create an order * Add 1 product A for a total of €10 * Set a partner * You should get 10 points * Save the order * Reload the saved order * Change the quantity of product A to 2 > Observation: You still have 10 points instead of 20 Why the fix: ------------ When saving the order, it is synced with the backedn and the comboLines are reloaded from the backend when reloading the order. However, it becomes an empty list and the line would be treated as a combo header. This backport a part of this commit : https://github.com/odoo/odoo/pull/220828 opw-5118716
This update fixes a discrepancy in how tax reports are tested within several Odoo localization modules (l10n_at, l10n_dk, etc.). The change ensures tests accurately reflect the 'invoice label' used for tax information, leading to more reliable report generation. This improves the accuracy of tax reports for our international customers.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236497
This update fixes an issue where returning a received subcontracted product didn't properly decrease the purchase order quantity. Now, customers can accurately process multiple return and re-receipt scenarios, ensuring correct quantity tracking for subcontracted products. The change addresses a technical update related to Odoo 18.0's exchange workflow.
Original PR description
Problem: If a customer ends up returning their subcontracted products and then creates a second return to receive the products again the received quantity on the purchase order line updates…
Problem: If a customer ends up returning their subcontracted products and then creates a second return to receive the products again the received quantity on the purchase order line updates correctly. However, if they return the second receipt, then it increases the received quantity on the purchase order line instead of decreasing it. Purpose: This will allow a customer to process a chain of returns for subcontracted products while keeping the received quantity correct. I have removed the check for origin_returned_move_id because of the return for an exchange workflow in Odoo 18.0. This field does not get set because the exchange moves should be independent of their origin moves. Steps to Reproduce on Runbot: 1. Create a purchase order for a subcontracted product. 2. Validate the receipt on the purchase order. 3. Return the receipt and validate it. 4. Create a return of the previous return and receive the products again. 5. Create a return of the return from the previous step and validate it. 6. Observe the received quantity on the purchase order line increased instead of decreasing after step 5. opw-4839366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses minor improvements and bug fixes within the Odoo spreadsheet component. Specifically, it ensures correct alignment of numeric data when exporting to Excel and incorporates a recent release (17.0.84) with related enhancements. This ensures the spreadsheet functionality continues to operate smoothly and reliably.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ae6422403 [REL] 17.0.84 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ae6422403 [REL] 17.0.84 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/eb07d192c [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/3afa12f85 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update ensures that the cost of goods sold (COGS) is correctly reversed when creating a credit note after a downpayment on an invoice. Previously, the system didn't properly account for the downpayment, leading to incorrect journal entries. This fix addresses a discrepancy in how downpayment credit notes are processed.
Original PR description
this PR is a backport of https://github.com/odoo/odoo/pull/226809 **Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs…
this PR is a backport of https://github.com/odoo/odoo/pull/226809 **Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on ordered quantity - set the category of the product as avco and "inventory valuation" of the category as automated - set an onhand quantity and a positive cost - create a SO for 1 quantity of this product and confirm - click on create invoice, select downpayment percentage and 25% - click on create draft and confirm it - click on create invoice, select regular, create draft - confirm and select credit note - write something in the reason field and click on reserve - confirm it **Current behavior:** if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once) **Expected behavior:** There should be: - A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product. - A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product. **Cause of the issue:** Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/pull/186486/commits/b819ee9570faa17ea143a1b924bce995ded89f6f), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx. https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/stock_account/models/account_move.py#L116 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit. https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/stock_account/models/account_move.py#L133 Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/sale_stock/models/account_move.py#L173-L174 As a consequence, - qty_to_invoice will become - qty_to_invoice - account_move will be populated - therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/sale_stock/models/account_move.py#L176-L184 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative. https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/stock_account/models/product.py#L842 **fix** The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one : - SO for qty of 10 (product invoiced on delivered qty). - 100% downpayment. - deliver 6. - invoice. In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id. opw-5423517
This update resolves an issue that prevented users from exporting SAFT reports for Austrian companies when no contact information was defined. Previously, the system would generate an error message. Now, the SAFT export process functions correctly, ensuring accurate reporting for all Austrian businesses.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear no-task
This update corrects a bug in how the system determines if a stock location is a sub-location of another. The fix replaces a potentially misleading comparison with a more reliable method, preventing errors in location-based processes. This ensures more accurate stock management and avoids potential test failures.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350