Thursday, January 15, 2026
76 changes · saas-19.1
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#98389This update resolves a random failure in a key stock management tour. The issue stemmed from a timing conflict during the unpacking of pallets, leading to incomplete actions. The fix adds a verification step to ensure the first pallet line is fully unpacked before proceeding, improving tour 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 pull request addresses a technical update to the Belgian payroll module (l10n_be_hr_payroll) to align with recent refactoring efforts. The change ensures accurate processing of DmfA declarations, maintaining the correct functionality for payroll calculations in Belgium. This update is a routine maintenance fix.
Original PR description
Forward-Port-Of: odoo/enterprise#104175
This update ensures that the DDT number is correctly included in delivery reports sent to customers. Previously, the DDT number was missing from the attached PDF, causing confusion. The fix changes the process to generate the DDT number before sending the email, resolving this issue.
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 fixes a problem where incorrect credentials caused misleading error messages when sending invoices. The change adds a test to ensure the correct error is displayed, preventing confusion and ensuring invoices are processed properly. This improves the reliability of the HR EDI module.
Original PR description
Fixing incorrect error display that occurred while trying to send an invoice to MER with incorrect credentials set up. (no task/error ID) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243745 Forward-Port-Of: odoo/odoo#243489
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 the need for 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 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 a restriction that prevented non-administrator users from updating GI CFDI sequences. Previously, sequence updates required elevated privileges, limiting functionality. Now, all users can update these sequences, streamlining the process and improving efficiency.
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 resolves an issue where FrontDesk hosts with limited access were unable to check out visitors via email. The fix allows hosts to complete the checkout process by running actions with elevated permissions, ensuring a smooth visitor experience. This improves usability for FrontDesk staff.
Original PR description
Steps to reproduce: * Create a visitor record with a host who has only FrontDesk user access. * Ensure Notify with Email is enabled on the station. * Click Check Out Visitor from the received email → access error appears. Issue: * Hosts with only FrontDesk user access received an access error when clicking the “Check Out Visitor” button from the email notification. * They were unable to complete the visitor checkout process. Fix: * Run the checkout action with sudo() so the host can successfully check out the visitor from the email link. Impact: * Hosts can now check out visitors without encountering permission errors. task-5373026 Forward-Port-Of: odoo/enterprise#101179
This update streamlines the process for inviting users to channels. The redundant 'invite people' button has been removed from channel types with member lists, consolidating the invitation option within the member list panel. This improves user experience and reduces visual clutter.
Original PR description
*=im_livechat Previously, channels with `memberList` had two ways to invite new users — one through the header action button and another via the member list panel. This caused redundancy since both performed the same action. This commit removes the header invite button for channel types that already have a member list and keeps only the invite option inside the member list panel. The behavior for chat-type channels remains unchanged. In addition, the invite button in the member list panel now opens a proper dialog instead of a popover. Invite buttons in other areas, such as the sidebar and chat window actions, remains unchanged for ease of access enterprise: https://github.com/odoo/enterprise/pull/98457 Task-5406953
This update streamlines the process of inviting new users to WhatsApp channels by utilizing the existing member list panel's invitation button. This change, stemming from a previous update, simplifies user onboarding and removes a redundant action from the channel interface. It ensures a more consistent and efficient user experience.
Original PR description
After https://github.com/odoo/odoo/pull/233389, we rely on the member list panel's invite button to invite any new user and remove the dedicated invite action form the thread header action list for all channel type that have member list. This commit adapts the failing test for the same. community: https://github.com/odoo/odoo/pull/233389 Task-5406953
This update resolves an issue where tests related to stock valuation in manufacturing were disabled. The fix ensures accurate calculations for product costs, particularly in subcontracting scenarios, by re-enabling the relevant tests. This improves the reliability of our manufacturing accounting processes.
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 Forward-Port-Of: odoo/odoo#234589
This update resolves several issues impacting the accuracy of account reports related to MRP (Material Requirements Planning) within the Odoo Enterprise system. The changes focus on improving the reliability of tests for key modules like 'mrp_workorder_hr_account', ensuring accurate financial reporting and data integrity. This resolves a previously identified bug.
Original PR description
Forward-Port-Of: odoo/enterprise#98924
This update resolves a technical problem preventing order data from being correctly saved in the Odoo POS system for Sweden. The fix involves renaming related fields in the user interface to ensure data synchronization with the database. This ensures accurate order tracking and reporting.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104321 Forward-Port-Of: odoo/enterprise#104180
This update ensures that website order taxes are recalculated accurately when a customer's address is changed. Previously, this process was limited, but this fix introduces a flexible mechanism to recompute taxes for draft website orders, preventing incorrect tax calculations. This improves the accuracy of pricing and order totals.
Original PR description
Followup of 290d77cde41295b28aa522025136b48f74abcfc5.
When updating a partner address that may impact the fiscal position, we will recompute the fiscal position (and taxes) for draft website orders.
But other modules may also need to recompute other records, so avoid repeating the recomputing, this commit introduces a hook to allow extending the subset of records for which we need to recompute the fiscal position and taxes.
As the extended domain may contain non-draft records, ensure we only recompute prices for draft orders.
opw-5365258
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243047This update fixes an issue where subscription and invoice calculations were incorrect after a partner's address was updated. The change ensures that fiscal positions and taxes are automatically recomputed when subscriptions are running or churned subscriptions are reopened, guaranteeing accurate tax and amount reporting.
Original PR description
When updating a partner address that may impact the fiscal position, we need to ensure the fiscal position (and taxes) are also updated on running subscription or when reopening a churned subscription. Otherwise the subscription and generate invoices won't have the correct taxes and amount. opw-5365258 Forward-Port-Of: odoo/enterprise#103802
This update hides the 'suggest next documents' tab within the signing feature from users who are not logged in. This ensures that sensitive document suggestions are only visible to authorized users, improving data security and privacy. The change was implemented as a fix to a previous vulnerability.
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
This update corrects an issue where half-day leave requests were incorrectly calculated as full days. The fix removes a problematic filter, ensuring that half-day leave requests with 'sandwich leave' enabled display the correct duration of 2 days instead of 4. This improves the accuracy of leave tracking for Indian companies.
Original PR description
**Steps:** 1. Install the `l10n_in_hr_holidays` module and create an Indian company 2. Create a time-off type that has `half-days` as the request unit and set "sandwich leave" to true 3. Create a leave request from December 12 to December 15, 2025 it should display a duration of 2 days instead of 4 **Cause:** The filter was removing leaves that had `half-day` set as the request unit **Fix:** The half-day filter is removed. In `_l10n_in_is_full_day_request` method we will check for actual half-day leave If the `request_date_from_period` and `request_date_to_period` are the same, then it is not considered a full-day leave, and it will not be calculated as a sandwich leave. Task-5427415 Forward-Port-Of: odoo/odoo#240542
This update resolves problems with how documents are linked to journal entries, ensuring invoices and vendor bills correctly move to the intended accounting folders and receive the correct tags. It corrects a previous issue where actions were executed in the wrong order, leading to documents being misfiled.
Original PR description
This PR addresses three related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Sync on Account Move Creation.…
This PR addresses three related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Sync on Account Move Creation. Fixed a regression (introduced in 2333367) where documents failed to move to the correct Journal folder and apply tags when creating a new account move. Also added a small refactor to flatten the structure. The tests added in Fix 3 would catch this regression in the future. **Fix 2:** Sync on Miscellaneous Entry Creation Previously, creating a Miscellaneous Entry (move_type='entry') from an existing document failed to move the document from its original location (e.g., "Finance") to the correct accounting folder. The existing sync logic explicitly skipped entries to avoid issues with multi-attachement invoices. **Fix 3:** Execution Order of Multi-Actions. Previously, multi-step server actions (e.g., 'Create Vendor Bill') executed child actions alphabetically. This caused the manual "Move to Taxes" action to execute after the record creation sync, effectively overriding the correct journal folder placement and moving the document to a generic folder (e.g. 'Taxes'). Changes: - Enforced a specific execution order: The document is now moved before the accounting record is created. This ensures the final automatic sync prevails. - Additionally, the action is temporarily embedded (pinned) on the intermediate folder during execution to allow the subsequent record creation to proceed even after the document has been moved to a new folder (which would otherwise fail consistency checks). Changes: - Extended `ir.attachment.write` to detect when a document is linked to an account.move of type 'entry'. - Triggers `_update_or_create_document` immediately upon linking to ensure tags and folders are synchronized. Task-5452729 Task-5452880 Forward-Port-Of: odoo/enterprise#103096
This update fixes a bug where email templates with images would sometimes duplicate themselves when saved. The change ensures all images load completely before processing, preventing errors and the duplication of content. This improves the stability and reliability of email template creation and management.
Original PR description
Problem: In Email templates, having an email with an image using `t-att-src` (Qweb) on save will duplicate the template. Cause: Images without a `src` attribute (or empty src) make `waitUntilImagesLoaded` fail immediately if the image loading promise rejects. Because the errors were not caught, the inline conversion process was interrupted and duplicating content. Solution: Use `Promise.allSettled` instead of `Promise.all` to ensure the system waits for all images to finish loading regardless of success or failure. Additionally, filter the query selector to strictly select images with a non-empty `src` attribute (`img[src]:not([src=""])`) to avoid processing invalid or dynamic Qweb images. Steps to reproduce: - Open An email template with Qweb image. - Do a change and save. - Observe the content is duplicated. opw-5489040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243725
This update resolves a technical issue within the Odoo Enterprise HR payroll module that could cause errors when creating rule parameters with future dates. The fix ensures that computed fields are correctly initialized, preventing a traceback and guaranteeing accurate payroll calculations. This improves the stability and reliability of the payroll process.
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#104346
Forward-Port-Of: odoo/enterprise#102924This update resolves an issue preventing credit notes created with DIAN support documents from successfully sending. The problem stemmed from an incorrect namespace being used, causing errors during the document generation process. This fix ensures credit notes with DIAN support documents can be properly sent, improving compliance and data accuracy.
Original PR description
**PROBLEM** When trying to create a credit notes using a journal with support documents, there is a lot of errors when sending the dian documents. **STEP TO REPRODUCE** 1. setup DIAN (knowledge page https://www.odoo.com/odoo/knowledge/5/knowledge/23114). 2. create a vendor bill, and then create a credit note with the DIAN support document journal. 3. Confirm and click on send DIAN documents. **CAUSE** `_get_document_nsmap()` uses the wrong namespace for credit notes. opw-5378540 Forward-Port-Of: odoo/enterprise#103821
This update fixes an issue where translated text within views was being incorrectly escaped, preventing it from displaying properly. The change ensures that translated strings are rendered as HTML, allowing for accurate and consistent display of localized content. This improves the user experience by correctly showing translated text in various Odoo views.
Original PR description
Following the semantic change in QWeb `t-call`, node attributes are now treated as function arguments. Previously, these were defined via `t-set`, which produced QwebContent capable of holding…
Following the semantic change in QWeb `t-call`, node attributes are now treated as function arguments. Previously, these were defined via `t-set`, which produced QwebContent capable of holding XML/HTML.
When `edit_translations` is active, translated strings are wrapped in `<span>` tags containing translation metadata. To maintain backward compatibility and allow in-place translation, values from `.translate` attributes are now explicitly marked as Markup safe elements. This ensures that the translation wrappers are correctly rendered as HTML rather than escaped text.
Exemple:
```xml
<t t-call="payment.submit_button">
<button><t t-out="submit_button_label"/></button>
</t>
<t t-name="payment.mytemplate">
<div class="modal-body">
<div class="float-end mt-2" t-att-data-provider-id="provider_sudo.id">
<t t-call="payment.submit_button" submit_button_label.translate="Pay"/>
</div>
</div>
</t>
```
When reading the views, `submit_button_label` value must be translated. We We want the button to be rendered with the translated value and not to display the escaped char like "<".
see: https://github.com/odoo-dev/odoo/commit/eb6e88a25050fff2bd09317739dd51ba451450df
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243473This update resolves a display problem in the General Ledger report when using analytic accounting. Previously, the report showed incorrect information and linked to the wrong journal entries. The fix ensures the General Ledger accurately reflects analytic account groupings, providing correct data and navigation.
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 pull request fixes a reporting issue related to Bebat, a Belgian organization recycling used batteries. It ensures that recycling tax charges are correctly identified as 'Special Agreement' (64) or 'Battery Collection and Recycling' (CAV) instead of the previous 'New Outlet Discount' (66) classification, 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
This update fixes an error in the Mexican payroll module that caused incorrect period end calculations when creating pay runs with schedules like '10 Days' or 'Bi-weekly'. The code was updated to align with the standard payroll method, ensuring accurate period determination for Mexican companies.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825 Forward-Port-Of: odoo/enterprise#104039 Forward-Port-Of: odoo/enterprise#102326
This update prevents public users from making changes to department configurations within the Employees app. Previously, they had unintended write access, which has now been corrected. This ensures data integrity and prevents unauthorized modifications to department settings.
Original PR description
**Steps to reproduce:** - Install Employees app - Login as public user - Go to Employees menu - Press on any employee to open its form view - Press on the department field - Try to edit the department configuration **Issue:** Public users can edit all the fields on the department configuration, except the Department's manager. This is should not be the case. **Solution:** Remove write access on department for public users. Task: 5384463 Forward-Port-Of: odoo/odoo#239027
This update resolves an issue where rental prices weren't being calculated correctly due to an error in how the system processed certain data. The fix ensures that rental prices are accurately computed, improving the reliability of rental agreements within the system. This impacts the accurate reporting and pricing of rental products.
Original PR description
Kwargs were wrongly extracted in an override, leading to a traceback because the same arguments were provided twice to the super call.
This update ensures that rating cards are only shown in the portal chatter for modules that specifically request them. Previously, rating cards were displayed even when not intended, leading to a cluttered user experience. This change improves portal clarity and focuses the rating feature on its core use cases.
Original PR description
*: test_mail_full Modules using portal rating can set an `data-display_rating` attribute when calling the portal chatter template to indicate whether they want the rating feature displayed. Currently, only two modules have this attribute set to true: ecommerce and elearning. For other modules that don't set this attribute, even if there is a rating, such as when rating a ticket in the helpdesk module, we don't want the rating card feature to be shown in portal chatter. This change ensures that the feature is only available if the module requests it. task-5347848 Forward-Port-Of: odoo/odoo#243495 Forward-Port-Of: odoo/odoo#243255
This 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, improving the customer experience and order accuracy.
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#243413 Forward-Port-Of: odoo/odoo#241251
This update fixes an issue where the 'Code' hint wasn't visible when a cursor was placed in an empty code block after syntax highlighting was implemented. The fix utilizes a native placeholder attribute in the textarea, ensuring the hint is consistently displayed for code blocks, improving the user experience within the HTML editor.
Original PR description
#### Description of the issue this PR addresses: - After syntax highlighting was introduced, placing the cursor inside an empty code block no longer displayed the 'Code' hint. - The hint logic gets the syntax-highlighing element instead of the `<pre>` element, and the `<pre>` is the child of syntax-highlighing node, and that is marked as data-oe-protected='true', so the`<pre>` is treated as a protected node and is not eligible for hint rendering. #### Desired behavior after PR is merged: - For code blocks, use the native placeholder attribute on the <textarea> and control its visibility based on focus. task-5473682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243042
This update resolves a bug where manually changed currency rates on invoices weren't updating correctly, leading to lost data. The fix now only recalculates rates and lines if the user hasn't modified them, ensuring accurate currency calculations for invoices with different dates than their creation.
Original PR description
in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded. So now, we only recompute the rate and the lines if the user didn't change it. Fix: https://github.com/odoo/odoo/pull/226124/changes/1b48d141d7260a262075555c4ab9cedc691d3551 Issue with Fix: Invoices posted on dates different from their creation date do not update their currency rates, even though they should. Comparing `invoice_currency_rate` to the expected rate at creation is a better guess. task-5477481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243832 Forward-Port-Of: odoo/odoo#242800
This update resolves an issue where group channels (DMs with fewer than 3 members) were displaying incorrect status information, such as an 'IM status' or 'back on' banner. By removing a specific calculation, the system now accurately reflects the channel type, leading to a more reliable and consistent user experience for group conversations. This ensures notifications and channel displays are correct.
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 change prevents the 'Update Prices' button from appearing on sales orders when a pricelist hasn't been set up. Previously, the button was incorrectly displayed, potentially confusing users. This ensures a cleaner user experience and avoids unnecessary actions when pricelists aren't in use.
Original PR description
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is…
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is visible even when no pricelist is set on the sales order. **Root cause:** - In the onchange logic (see [1]), show_update_pricelist is set to True based solely on the presence of order lines, without checking whether a pricelist is defined. **Solution**: - Update the condition so that button is shown only when sale order line is present and the current pricelist value is not the previous one. [1]: https://github.com/odoo/odoo/blob/849ec71acbaea0061fd4b13888a486e4aebb6463/addons/sale/models/sale_order.py#L801-L803 Before: <img width="1215" height="466" alt="image" src="https://github.com/user-attachments/assets/f29b1ccf-eec8-4114-b4c9-a8083947ad28" /> After: <img width="1207" height="428" alt="image" src="https://github.com/user-attachments/assets/e358b633-d11b-413d-94c4-3837c430eac4" /> opw-5414897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243410 Forward-Port-Of: odoo/odoo#241812
This update resolves a technical error that prevented users from creating and saving bank statements within the Accounting module. The issue stemmed from a problem accessing data within the system, now corrected by passing data as 'props'. This ensures the bank statement creation process functions correctly.
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#104072 Forward-Port-Of: odoo/enterprise#101232
This fix ensures that discounts applied through pricelists are correctly calculated even when a negative quantity is entered in the Point of Sale system. Previously, the system didn't apply the discount rule when a negative quantity was selected. This change corrects a discrepancy between the backend and frontend pricing logic.
Original PR description
Steps to reproduce: ------------------- 1. Create a pricelist with a rule of 50% discount on all product, and a `min_quantity` of ZERO. 2. In PoS select this pricelist, and add a product originally priced at 10; the pricelist is well applied and the new price is 5. 3. Now, from the numpad, click change the quantity from 1 to -1 (click on the "+/-" button. Observation: The pricelist rule is not applied anymore. The price is -10 and not -5. Why it's an issue ----------------- `getPrice` on frontend is a port of `_get_product_price` on product.pricelist. There, in `_is_applicable_for`, we apply the price rule if it's `min_quantity` is 0, regardless of the bought quantity. So there's a mismatch between applying the rule on backend and frontend. This worked well on 18.0, before 43bfda63faeb4713dbeb1d11457673aafaa544b4. opw-5431651 Forward-Port-Of: odoo/odoo#241608
This update fixes an issue where changes to the website footer (specifically structural edits like changing links to buttons) were lost after upgrading the 'Website' app. The fix ensures that edits made in one language are correctly applied across all languages, improving the reliability of website customizations. This prevents users from needing to re-apply changes after updates.
Original PR description
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view.…
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view. This happened because the update of the view did not take into account the possible delayed translations when updating it and the translations in specific views. This commit updates (and uses as source) the current versions, instead of the delayed ones. Steps to reproduce: - Install a second language for the website - Set the default language for the website to the second language - Edit footer by changing structure not just text (like changing a link to have a button appearance) - Upgrade the "Website" app - Bug: footer lost the last edit Steps to reproduce: - Install a second language for the website - Edit footer by changing structure not just text (like changing a link to have a button appearance) - (Observe that the change is not in the website in the second language) - Upgrade the "Website" app - Bug: the change is now in the website in the second language task-5248173 Fixes #233723 Forward-Port-Of: odoo/odoo#241677
A technical issue with WebKit was preventing users from correctly scanning barcodes on iOS devices. This resulted in a white square obscuring the scanning area. This update resolves the problem by addressing the underlying WebKit bug, ensuring accurate barcode scanning functionality for iOS users.
Original PR description
Issue ----- There is an issue in WebKit with mix-blend-mode https://bugs.webkit.org/show_bug.cgi?id=286619 Because of this issue, in barcode, the user gets a solid white square over the scanning zone, so they don't see the barcode being scanned. ----- Ticket: opw-5386846 Forward-Port-Of: odoo/odoo#243486
This update optimizes how Odoo handles web sockets, particularly when dealing with a large number of connected clients. By tweaking the delay in acquiring web socket cursors, the system now recovers more effectively from connection bottlenecks, preventing disconnections and maintaining performance under heavy load. This ensures a smoother experience for users.
Original PR description
Benchmarking with 4k connected clients, 1 message per second. | | Message dispatching | Cursor analysis | |-- |-- | -- | | Before|<img width="600" alt="image" src="https://github.com/user-attachments/assets/f02e7efc-4611-4356-8bef-386ff2b0a7da" />|<img width="600" alt="2_current_implementation__cursor_analysis" src="https://github.com/user-attachments/assets/04dce96e-74a6-4f1b-9918-a6c61913e7c4" />| |After|<img width="600" alt="image" src="https://github.com/user-attachments/assets/a9463484-7f69-4fcb-a248-5692893a8893" />|<img width="600" height="997" alt="8_tweak_delay_both_sleep__cursor_analysis" src="https://github.com/user-attachments/assets/34a2c233-5c36-4597-a55b-cfb89a41efcf" />| Forward-Port-Of: odoo/odoo#241788 Forward-Port-Of: odoo/odoo#241330
This update ensures that transfer links remain accurate after manufacturing merged production orders. Previously, the system incorrectly assigned default warehouse locations, causing issues with complex multi-location workflows. This fix guarantees the correct location is used for transfers, improving the reliability of manufacturing processes.
Original PR description
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in…
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054 because of the `m.location_id == move.location_final_id` part being false in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097 This is because, during the merge, `location_final_id` is not propagated to the new MO https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424 so when the new MO's `move_finished_id` gets computed https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822 it gets the MO's `location_final_id` https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202 which is false. This leads to to the move getting the warehouse's default stock location thanks to https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457 This is problematic for complex use cases with multi-locations and custom routes. It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one. Use case example ----- <details> <summary>Full use case</summary> - Enable multi-step routes - Create location "WH/Stock/L1" - Create location "WH/Stock/L2" - Create Operation Type "MO child" - Type of Operation: Manufacturing - Sequence Prefix: MOCHILD - Source Location: L1 - Destination Location: L2 - Create Operation Type "Push Transfer" - Type of Operation: Internal Transfer - Sequence Prefix: L2L1 - Source Location: L2 - Destination Location: L1 - Create Route "MO child" - Create Rule "Manufacture" - Action: Manufacture - Operation Type: MO child - Source Location: False - Destination Location: Stock - Create Route "2-step" - Warehouse: Main WH - Create Rule "L1 -> Virtual/Production" - Action: Pull from - Operation Type: MO child - Source Location: L1 - Destination Location: Virtual/Production - Create Rule "Push: L2 -> L1" - Action: Push To - Operation Type: Push Transfer - Source Location: L2 - Destination Location: L1 - Unarchive MTO - Edit MTO route - Create Rule "L1 -> Virtual/production (MTO)" - Action: Pull - Operation Type: "My Company: Manufacturing" - Source Location: L1 - Destination Location: Virtual/Production - Supply Method: Trigger another rule - Create product "Main product" - Create product "Child product" - Routes: "MO child" & MTO - Create product "Material" (consumable) - Create BOM - Product: "Main product" - Component: "Child product" - Create BOM - Product: "Child product" - Component: "Material" - Create MO for "Main product" - Misc/Component Location set to L1 - Duplicate the MO - Merge child MOs & produce - Validate merged MO transfer to L1 - Go back to one of the "Main product" MO > Component quantity is 0 </details> ----- Ticket: opw-5144196 Forward-Port-Of: odoo/odoo#242801 Forward-Port-Of: odoo/odoo#240695
This update ensures that product attributes are correctly displayed on refund orders and receipts. Previously, when a customer refunded an order with variants, the attributes were lost during the refund process. This fix correctly transfers the attributes from the original order to the new refund order, improving the accuracy of refund records.
Original PR description
**Steps to reproduce:** - Make an order with a product that has variants and chose whatever in the popup - Pay for that order, then refund it - The attribute is not shown on the orderline anymore - The attribute is not shown on the receipt either **Why the fix:** When making a refund, we are actually making a new order, so we need to move the data from the old order to the new refund order. During this transit, the *attribute_value_ids* was forgotten on the moving lines, so the attributes were lost. We now give the old attributes to the new line. opw-5393332 Forward-Port-Of: odoo/odoo#243300 Forward-Port-Of: odoo/odoo#240602
This update resolves an issue where saving accounting reports with incorrect formulas would generate an error. The fix ensures the system handles invalid 'Prefix of Account Codes' settings gracefully, preventing report failures and improving data reliability. This change impacts the accounting report generation process.
Original PR description
Saving an accounting report with an invalid ``Prefix of Account Codes`` formula will raise a traceback. Steps to reproduce the error: - Install ``accountant`` module - Go to Accounting >…
Saving an accounting report with an invalid ``Prefix of Account Codes`` formula will raise a traceback. Steps to reproduce the error: - Install ``accountant`` module - Go to Accounting > Configuration > Accounting Reports > Open any report > Add a line > Add name > Add a line > Add a Expression > Computation Engine: Prefix of Account Codes > Formula: test( > Save the report Traceback: ```py TypeError: 'NoneType' object is not subscriptable ``` https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/account/models/account_report.py#L661-L662 Here, if the token does not match the regex, ``token_match`` will be ``None``, The code then accesses ``token_match['prefix']`` which leads to the above traceback. https://github.com/odoo/odoo/blob/312964fdf68609dbd0fc1bb3be609b50e171b0c3/odoo/tools/translate.py#L556 Here, no translation language is detected by ``_get_lang``. To resolve this, ``self.env._()`` is added instead of ``_()`` at below line. https://github.com/odoo/odoo/blob/312964fdf68609dbd0fc1bb3be609b50e171b0c3/addons/account/models/account_report.py#L646-L648 sentry-7175078855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243283
This update resolves an issue where failed IoT driver actions were incorrectly recorded, preventing them from being re-executed. Now, actions are only registered upon successful completion, enhancing the reliability and efficiency of IoT driver operations. This change improves the overall stability of the system.
Original PR description
We currently reject an action if it has the same id of a previous one. If the action failed, we still registered it, making it impossible to be executed again. We now only register if the action succeeds. Forward-Port-Of: odoo/odoo#243913 Forward-Port-Of: odoo/odoo#243247
This update resolves an issue where clicking 'Back' in the self-order POS system sometimes caused incorrect product additions to the cart. The fix clarifies the trigger for product clicks, preventing confusion and ensuring accurate cart updates. This improves the overall reliability of the self-order experience.
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-pr
Forward-Port-Of: odoo/odoo#243749This update addresses a technical issue within the Odoo spreadsheet module where pivot tables would generate tracebacks when encountering fields that were no longer present due to data changes or module removals. The fix ensures the spreadsheet functionality remains stable and reliable, even with evolving data structures. This prevents disruptions to users generating reports.
Original PR description
Task: 5085724 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228166
This update resolves a technical issue that caused a traceback error when creating pivot tables in the spreadsheet reports. The fix ensures that pivot tables function correctly, even when certain data dimensions are missing, improving the reliability of reporting. This enhances the usability of the enterprise spreadsheet functionality.
Original PR description
Task: 5085724 Forward-Port-Of: odoo/enterprise#103369
This update fixes an issue where follower list avatars weren't consistently displayed with the correct proportions, particularly for non-square images. The change utilizes a standard Odoo class for avatars, ensuring all images are displayed correctly and maintaining a professional appearance. This improves the visual quality of the follower list.
Original PR description
Before this commit, follower list menu had avatar that do not preserve ratio of avatars. This is noticeable for avatars that have ratio quite different from 1:1, like 3:2 or 2:3 or even less squarish. This happens because of missing `.o_object_fit_cover`, that [1] erroneously removed from REF of follower template part into its own component. This commit uses an equivalent but more official solution: `.o_avatar`, which is a classname dedicated for avatars, which has `.o_object_fit_cover` property. Task-5412078 Before / After <img width="638" height="526" alt="Screenshot 2026-01-12 at 17 23 54" src="https://github.com/user-attachments/assets/b8d3a921-52a8-48b7-a0d0-5fbfdd33a92c" /> <img width="640" height="528" alt="Screenshot 2026-01-12 at 17 23 33" src="https://github.com/user-attachments/assets/8070420c-f341-4085-bcb2-2fba060765f0" /> [1]: https://github.com/odoo/odoo/pull/200382 Forward-Port-Of: odoo/odoo#243684 Forward-Port-Of: odoo/odoo#243328
This update fixes a bug where changes to the analytic distribution widget weren't being saved correctly when the user navigated away from the field. Now, edits to the analytic distribution are automatically saved when the user clicks elsewhere, mirroring the behavior of other key fields like invoices. This ensures data consistency and a smoother user experience.
Original PR description
**Issue** When editing a line on the reco widget, close and keep change on analytic widget on unfocus **Steps to Reproduce** 1. Activate Analytic Accounting 2. Go on the Bank Reconciliation Widget 3. Edit a line 4. Change the Analytic Distribution. 5. Click elsewhere. 6. The Analytic Widget should close and keep the changes. (as it does on invoices) **Fix** Properly detect the condition for closing the widget. task-5232476 Forward-Port-Of: odoo/odoo#234398
This update fixes an issue where only the first attachment from an expense was included in the generated journal entries. The change ensures that all attachments associated with approved expenses are now correctly copied, improving accuracy and providing complete expense documentation.
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#243962 Forward-Port-Of: odoo/odoo#241044
This update fixes a problem with how mass mailing tests wait for the ThemeSelector to load, ensuring more reliable test results. Additionally, the commit optimizes test execution by removing unnecessary assets, reducing test run times by 10-40%.
Original PR description
The ThemeSelector rendering was optimized ([commit]) to minimize UX transition delays for the user, but that makes it a bit tricky to wait for in tests. This commit adds a function to properly wait for everything required to select a theme/favorite by clicking on it, in order to reduce non-determinism in `mass_mailing` tests. [commit]: https://github.com/odoo/odoo/commit/0f7ee1764e8b59029003c6ad7269e185b30c6b43 It also removes some assets loading during `mass_mailing` tests that are not relevant. This helps shave off 10-40% test time per test, depending on the complexity of the test. runbot-error-237513 runbot-error-237747 runbot-error-237769 runbot-error-237770 runbot-error-237772 task-5500038