Thursday, January 15, 2026
35 changes · saas-19.1
New functionality added to Odoo
This update introduces a new connector to seamlessly integrate Lazada sales orders into Odoo. It automatically imports orders from multiple Lazada accounts, synchronizes inventory levels, and facilitates shipment arrangements, streamlining the fulfillment process for Lazada-based sales.
Original PR description
* Authorize Lazada shop to be accessed via Lazada API * Import orders from multiple accounts and shops Orders are matched with Odoo products based on their internal reference (item_id or model_id in Lazada) Support for both Fulfillment by Lazada (FBL), Fulfillment by Merchant (FBM): FBL: Importing the completed orders FBM: Delivery information is fetched from Lazada, track and synchronize the stock level to Lazada. * Push inventory levels of matched products to Lazada * Arrange shippment for orders and download shipping label to Odoo task - 3478992 Forward-Port-Of: odoo/enterprise#83214
Enhancements to existing features
This update improves the Odoo Guatemala localization by adding necessary accounting accounts and configuring asset models for managing fixed assets. This allows businesses operating in Guatemala to accurately track their financial transactions and depreciation schedules within Odoo.
Original PR description
This commit updates the Guatemala localization to include missing accounts and configures the Asset Models for fixed assets management. Changes: -Updated `account.account` to include new accounts for fixed assets and expenses. -Added `account.asset` data to handle automated depreciation for various asset types. task-5149265 Forward-Port-Of: odoo/odoo#240487
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 streamlines the setup and management of Fiskaly integration for Austrian companies within Odoo Enterprise. Key changes include automated authentication attempts, clearer user guidance through alerts, and a simplified interface for credential generation and management. These improvements enhance the user experience and ensure proper Fiskaly configuration.
Original PR description
Task: [#5354476](https://www.odoo.com/odoo/project/1737/tasks/5354476) --- The Fiskaly configuration for Austrian companies has been edited: - Generating new credentials will try to authenticate right after generating them. - The *Test Fiskaly* buttons is now only visible in debug mode. - The *Generate Credentials* button won't be visible if the authentication has been successful except if the user is in debug mode. - The *Authenticate Keys* button is only available when the authentication has failed. - The *Manage by Odoo* checkbox has been removed and we force its value to True when generating new credentials. - An alert is displayed to guide the user depending on the state of the Fiskaly configuration (not authenticated, must regenerate credentials, etc). Forward-Port-Of: odoo/enterprise#100583
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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