Daily updates from Odoo
Thursday, February 12, 2026
176 changes
42 changes
Resolved issues and error corrections
A previous issue caused a timeout error in the website builder when adding elements like images, specifically when the system waited for user input after a dialog appeared. This update removes the timeout for these actions, preventing the error and ensuring a smoother user experience. It resolves a frustrating bug that prevented users from adding elements to their websites.
Original PR description
In [0] was added a timeout on operations, as an heuristic to detect when an operation is stuck. Unfortunately, when an action opens a dialog, waiting for the user to choose may go over the timeout limit, thus triggering the timeout. The timeout should be deactivated for those type of actions. This commit sets `canTimeout = false` on actions that open a dialog and wait for user choice in the `apply` method. Steps to reproduce: - Open website builder - Drop `s_sidegrid` snippet - Click on "Add Elements" option: Image - Wait 10sec - Bug: It show the error message "A technical issue occurred..." [0]: https://github.com/odoo/odoo/commit/6df83abb35c95ab42e55d9a08cf6c411efa64b3e Forward-Port-Of: odoo/odoo#248258
This update corrects a recent accidental removal of tests related to self-billing XML generation within the account_edi_ubl_cii module. These tests are crucial for ensuring invoices are correctly formatted for electronic billing, particularly in compliance with industry standards. The fix ensures continued accurate invoice export functionality.
Original PR description
Accidentally removed by 4247eac4a84c. task-none Forward-Port-Of: odoo/odoo#245954
This pull request fixes a minor typo in the Italian electronic invoice (EDI) system. The title ‘Fattura Electronica’ was incorrectly displayed; it has been corrected to ‘Fattura Elettornica’. This ensures accurate invoice processing and compliance with Italian tax regulations, preventing potential errors.
Original PR description
The title Fattura Electronica is wrong it should be Fattura Elettornica Asked by TSB 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#248153
This update fixes an issue where using the down arrow key within a table in the Powerbox interface caused the cursor to jump unexpectedly. The fix ensures that the Powerbox navigation continues correctly within the table, providing a smoother and more reliable user experience. This improves the usability of the To-Do module and other applications utilizing the table editor.
Original PR description
### Steps to Reproduce: - Go to To-Do & create a table (e.g.: /table). - Place the cursor in the last cell of the table. - Press / to open the command dialog (focus is on Heading 1). - Press Arrow Down. - Notice that cursor comes out of table and focus is as at Heading 2. ### Description of the issue/feature this PR addresses: - ArrowDown first triggers table cell navigation & cursor moves out of table. - Powerbox keydown handler runs afterward & focus moves to the next item. ### Desired behavior after PR is merged: - Powerbox keydown listener runs before table navigation (capture phase) stopImmediatePropagation() prevents table navigate cell. Cursor stays inside table cell & powerbox focus moves to the next item. task - 5895390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248064 Forward-Port-Of: odoo/odoo#247121
This update resolves an issue where the Stock Forecasted report incorrectly displayed stock quantities after a draft repair order was deleted. The fix ensures that related stock moves are properly cancelled when a draft repair order is removed, providing accurate stock reporting.
Original PR description
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in…
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in *draft* state (do not confirm). * In the **Parts** tab, add the storable product with the operation type set to *Add*. * Open the **Stock Forecasted** report for the added product. Note the quantity shown under *Outgoing Draft Transfer*. * Delete the **Repair Order**. * Open the **Stock Forecasted** report for the same product again. **Observed behavior:** * The quantity still appears in the **Stock Forecasted** report under *Outgoing Draft Transfer* even after the repair order is deleted. **Cause:** * Deleting a draft repair order triggers `_unlink_except_confirmed`. * This method prevents related stock moves from changing their state to cancel when the repair order is deleted. * The *Outgoing Draft Transfer* value is calculated as the sum of quantities of stock moves in draft state at draft state. https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49 https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90 * As a result, deleting a draft repair order leaves related stock moves in draft state, causing them to appear under *Outgoing Draft Transfer* https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335 **Fix:** * Ensure that related stock moves are properly cancelled when a draft repair order is deleted. --- opw-5449323 Forward-Port-Of: odoo/odoo#248155 Forward-Port-Of: odoo/odoo#241970
This update resolves an issue where the HTML editor would incorrectly retain selections of tables and separators after the user clicked outside the editor. Now, when you click outside the editor, all selected content – including text, tables, and separators – is properly deselected, providing a more consistent and intuitive user experience.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In Todo, Type some text. - Insert a table and a separator. - Select text along with table and separator. - Click outside the editor. The text is deselected but table and separator are still selected. **Desired behavior after PR is merged:** Custom selection such as table and separator is deselected along with browser selection when clicking outside the editor. task-5479981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247962 Forward-Port-Of: odoo/odoo#243484
This update resolves a sporadic error related to image loading in the Odoo web interface. The change ensures the system waits longer for image updates, preventing a common issue caused by the time it takes to encode image data. This improves the overall responsiveness and reliability of image display.
Original PR description
Encoding the data to base64 can take some times. Before this commit we used this code: ```js await runAllTimers(); await animationFrame(); ``` Now we explicitly wait for the change to happen as awaiting an animation frame can't be enough. runbot-error-237568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248166
This update fixes an error that occurred in the Point of Sale module when a unit of measure (like 'Pack of 6') was deleted. Previously, the POS module would fail to load if this UoM record was no longer present. This change ensures the POS module functions correctly even after users manage their UoM records.
Original PR description
Currently, an error is produced when loading the pos module when a referenced UoM record (e.g., Pack of 6) has been deleted by the user.
**Steps to Reproduce:**
- Install Sales Module.
- Enable **"Units of Measure & Packaging"**.
- Delete the **"Pack of 6"** Units.
- Install POS.
**Error:**
```
ParseError:
while parsing /home/odoo/src/odoo/saas-19.1/addons/point_of_sale/data/point_of_sale_data.xml:38, somewhere inside <record id="uom.product_uom_pack_6" model="uom.uom">
<field name="is_pos_groupable">True</field>
</record>
Exception:
Cannot update missing record 'uom.product_uom_pack_6'
```
The POS module overrides `uom.product_uom_*` records. If the original UoM record has been deleted, the override fails because the record no longer exists.
sentry-7237815280
Forward-Port-Of: odoo/odoo#246940This update resolves an issue where event tickets with unlimited seats (seats_max=0) incorrectly showed as 'sold out' when the event itself had a limited number of seats. The fix ensures that these tickets accurately reflect the event's availability, providing a more reliable POS experience for customers.
Original PR description
We had a bug when selling event tickets in POS where tickets with seats_max set to 0 (which should mean unlimited) appeared as sold out when the event had seats_limited enabled. Steps to reproduce:…
We had a bug when selling event tickets in POS where tickets with seats_max set to 0 (which should mean unlimited) appeared as sold out when the event had seats_limited enabled. Steps to reproduce: ------------------- * Create an event with seats_limited=True and seats_max > 0 * Create a ticket for that event with seats_max=0 (unlimited) * Open POS and view the event product > Observation: Ticket appears as "Sold out" instead of showing available seats Why the fix: ------------ The frontend logic only treated tickets with seats_max=0 as unlimited when the event itself was not limited (!event.seats_limited). However, according to the backend logic, seats_max=0 means the ticket is unlimited regardless of the event's limitation status. When the event is limited, unlimited tickets should still respect the event's seats_available limit, not show as sold out. We now check for seats_max=0 independently of event limitation. If the event is not limited, tickets with seats_max=0 are fully unlimited. If the event is limited, we use the event's seats_available value (since the ticket doesn't constrain availability but the event does), ensuring correct display of availability status. opw-5475803 Forward-Port-Of: odoo/odoo#246102
This update fixes an issue where the channel invitation dialog was not taking up the full width of the modal window. Previously, it was limited, causing it to appear smaller than intended. This change ensures the dialog displays correctly and provides a consistent user experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/244777 Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Open "General" in…
Backport of https://github.com/odoo/odoo/pull/244777 Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Open "General" in discuss app - Click on Sidebar "Channel Actions" - Click on "Invite People" => Invitation dialog takes about half of the width of modal. This happens because the channel invitation was wrongly assumed to be inside a resizable panel, and thus the size was limited by the max width when in resizable panel. The rule to determine whether the action is in a resizable panel was poor: any action panel in discuss app was considered as resizable. This commit fixes the issue by limiting the responsive sizing, intended only for resizable panel, only when the action panel has the `.o_resizable_panel`, which is specific to when action panel is being used inside resizable panel. Task-5804100 Before / After <img width="625" height="231" alt="Screenshot 2026-01-20 at 16 12 31" src="https://github.com/user-attachments/assets/10c02939-c4c1-47fa-82f8-4d8d037d3f0c" /> <img width="621" height="231" alt="Screenshot 2026-01-20 at 16 12 18" src="https://github.com/user-attachments/assets/eec1447c-cb42-4751-b17a-ff7b2e70b8e9" /> Forward-Port-Of: odoo/odoo#247636
This update resolves a technical issue that caused tracebacks when creating invoices for kit products using AVCO or FIFO valuation methods. The fix addresses a problem where the system incorrectly assumed a single product cost method for multi-component kits, leading to calculation errors. This ensures accurate cost of goods valuation for kit sales.
Original PR description
**Issue**: The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback **Steps to reproduce**: - Create a kit product with 2 components: - Inventory…
**Issue**:
The computation of cogs value, in AVCO (or FIFO) setup with kit of several component leads to traceback
**Steps to reproduce**:
- Create a kit product with 2 components:
- Inventory tracking enabled
- Use a category configured with AVCO and Perpetual (at invoicing) valuation
- Create a SO for the kit product and confirm it
- Go to the associated delivery and validate it
- Create and post the invoice on the so -> A traceback occurs
**Cause**:
In `_get_cogs_price_unit`, the code accesses `self.product_id.cost_method` assuming a singleton: https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/stock_move.py#L245 but `self.product_id` can be a multi-recordset when the sale line corresponds to a kit with multiple components https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/stock_account/models/account_move_line.py#L67-L68 https://github.com/odoo/odoo/blob/5d2e4b0f3fa8cdf2a977db05c7c2565b06ca2513/addons/sale_stock/models/account_move.py#L155-L156
which causes the traceback.
**solution**
The solution has been inspired by this:
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228
opw-5880383
Forward-Port-Of: odoo/odoo#247775This update resolves an issue preventing custom JavaScript code added to the website from functioning properly. A recent change removed a key identifier, causing the system to misinterpret custom scripts. This fix ensures that developers can reliably add and use their own JavaScript to enhance the website's functionality.
Original PR description
[FIX] website: enable custom javascript on website Steps to reproduce the problem: - Go to the "HTML/ CSS Editor". - Go to the JS tab. - Uncomment the example and save. -> Problem: the confirmation…
[FIX] website: enable custom javascript on website Steps to reproduce the problem: - Go to the "HTML/ CSS Editor". - Go to the JS tab. - Uncomment the example and save. -> Problem: the confirmation dialog does not appear. The problem is that since [1], `/* @odoo-module */` has been removed from the file as since [2], js files in `/static/src` and `/static/tests` are considered as odoo module without the need of the annotation `odoo-module`. In order to understand the problem, here is a summary of what happens when a custom js code is saved; - An attachment is created with the custom js code. - An asset is created to replace the user custom rules of `user_custom_javascript.js` by the one of the newly created attachment. Because the url of the newly created attachment looks like `/_custom/web.assets_frontend_lazy/website/static/src/js/user_custom_javascript.js`, the transpiler does not recognize it as an odoo module. task-5925607 [1]: https://github.com/odoo/odoo/commit/6d2fda172ec9cc7642abe9625ca486c7769e8297 [2]: https://github.com/odoo/odoo/commit/5f2c505836002ac7851c29c28d612f721d467bc4 Forward-Port-Of: odoo/odoo#247959
This update fixes an issue where duplicate GS1 serial or lot numbers could be created when using the 'Default GS1 Nomenclature'. The change allows for the creation of multiple serial numbers with the same name, ensuring data integrity and preventing errors in inventory tracking. This improves the reliability of our stock management system.
Original PR description
## Issue When using the *Default GS1 Nomenclature*, it is possible to create multiple lots/serial numbers with a same name if that name matches a barcode rule pattern. ## Steps to reproduce 1.…
## Issue
When using the *Default GS1 Nomenclature*, it is possible to create multiple lots/serial numbers with a same name if that name matches a barcode rule pattern.
## Steps to reproduce
1. Install *Inventory* (`stock`)
2. In Settings, enable *Lots & Serial Numbers* and set *Barcode Nomenclature* to *"Default GS1 Nomenclature"*
3. Create a product tracked *By Unique Serial Number* or *By Lots*
4. In Inventory > Products > Lots / Serial Numbers, create a lot/serial number named *"101"* and set the product to the one created in the previous step
- The name *"101"* matches the pattern of the rule *"Batch or lot number"* (`(10)([!"%-/0-9:-?A-Z_a-z]{0,20})`)
5. Create a second lot/serial number with the same name and the same product
6. **The second lot/serial number is succesfully created**
## Cause
When comparing a (new) `stock_lot.name` to existing `stock_lot`s, the potential rules at the start of the name are removed by the `gs1_decompose_extended` method [here](https://github.com/odoo-dev/odoo/blob/e06282df3a7482cc327d3124e6c2b1c8bc55c2f0/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L116-L125). This results in comparing **the end** of the new lot/serial number with **the entire** name of existings serials.
## Solution
Commit https://github.com/odoo/odoo/commit/3513b189a225ca52fc9fae94693f00f43ded71aa introduced the `skip_preprocess_gs1` context flag. This flag allows to skip the step that removes the start of the new lot/serial number before comparing it to existing serials.
## Test
The test for this commit is added in `stock_barcode` by [this PR](https://github.com/odoo/enterprise/pull/104720)
opw-5477003
Forward-Port-Of: odoo/odoo#244427This update resolves a problem that prevented users from sending invoices via PEPPOL, resulting in an error message. The fix ensures that attachments are correctly processed during the PEPPOL invoice sending process, allowing invoices to be sent without interruption. This improves the reliability of the accounting module for businesses using PEPPOL.
Original PR description
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an…
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an invoice: * Customer: [a Belgian customer with VAT] * Invoice Lines: [a line with a tax] - Confirm the invoice - Send the invoice via PEPPOL **Issue:** A UserError is raised: "You cannot remove parts of the audit trail.". **Cause:** The audit trail prevent modifying an attachment. When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment. During the process, "res_model" and "res_id" fields of the attachments are set to the message record. Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error. However, it fails because the value is still in cache. **Solution:** Invalidate these fields as it is done when sending the invoice without PEPPOL. https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20 opw-5916696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248220 Forward-Port-Of: odoo/odoo#247949
This update addresses a minor visual issue with the account partner warning message. The change improves the appearance of the warning line, making it more user-friendly. This ensures a cleaner and more professional experience for users managing their accounts.
Original PR description
Adjusting the warning line to look better. task-5909566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247342
This update resolves an issue where pressing the Tab key in the Live Chat interface would trigger an error. A safeguard has been added to the system to prevent this, ensuring a smoother and more reliable user experience when navigating messages with the Tab key.
Original PR description
**Steps to Reproduce:** Install 'Live Chat' Open any record with a chatter Click Send Message to focus the composer Press the 'Tab' key on the keyboard **Current behavior before PR:** A traceback occurs because the code attempts to read 'channel_type' from a channel field that is undefined in standard threads. **Desired behavior after PR is merged:** A guard is added to the channel field. Pressing Tab no longer causes an error. task-5925393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where serial numbers assigned to products during repair orders would disappear from the system. The fix ensures that serial numbers are correctly associated with stock movements, even when starting with generic stock, improving accuracy and traceability in repair processes. This prevents data discrepancies and ensures proper tracking of serialized items.
Original PR description
Steps to reproduce: 1. Create a storable product with tracking set to 'By Quantity'. 2. Update the Quantity on Hand (e.g., 100 units). 3. Change the product tracking to 'By Serial Number'. 4. Create…
Steps to reproduce: 1. Create a storable product with tracking set to 'By Quantity'. 2. Update the Quantity on Hand (e.g., 100 units). 3. Change the product tracking to 'By Serial Number'. 4. Create a Repair Order for this product. 5. Add a line, select a specific Serial Number, and click Save. 6. Observe that the serial number disappears. Cause: When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation. Solution: In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid. opw-5156267 Forward-Port-Of: odoo/odoo#248094 Forward-Port-Of: odoo/odoo#247150
This update corrects and enhances the tax descriptions and names used in the Belgian localization for Odoo's point-of-sale restaurant module. The changes include accurate translations, German translations, and a fix to ensure the 21% S.INC tax is correctly applied as an included tax. This ensures accurate reporting and compliance for Belgian businesses.
Original PR description
In this commit[^1] the tax descriptions and names for the Belgian localization were added/updated. However, some names or descriptions were either not fully correct, poorly translated, or not translated at all. In this commit, we revised them all and added German translations for everything as well. [^1]: https://github.com/odoo/odoo/commit/c7b39c5ad4afba7e61265773b87f500469ace91b Forward-Port-Of: odoo/odoo#248060 Forward-Port-Of: odoo/odoo#247036
This update fixes a technical issue that could have caused errors in the Point of Sale system. Specifically, it addressed a situation where accessing product information could lead to an endless loop if the same data was defined in multiple product models. This change ensures data is accessed reliably, improving system stability.
Original PR description
Before this commit, if a getter was defined in both product.product and product.template models, and the getter returned a falsy value (like false or an empty string), it could lead to infinite recursion when accessing the property. This was due to the way the models fell back to each other to retrieve the property value. opw-5886320 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246272
This update fixes a potential issue where invoices generated from Point of Sale (PoS) orders would incorrectly round amounts when cash rounding wasn't properly configured. Previously, if cash rounding was disabled or only applied to cash payments, the invoice would still be linked to the rounding method, leading to inaccurate invoice line totals. This change ensures invoices are only rounded when cash rounding is enabled, maintaining accurate financial reporting.
Original PR description
Before this commit, when a rounding method was set in the PoS, but the cash rounding was not enabled, or only enabled for cash payments and the order did not contain any cash payment, the generated invoice would still be linked to the rounding method. This could lead to unwanted rounding on the invoice lines. opw-5864642 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247223
This update resolves a bug that caused Odoo module updates to fail when encountering certain field types (like 'Char') during the update process. The fix adds a check to ensure fields are of the correct type ('selection' or 'reference') before attempting to access their 'ondelete' attribute, improving update stability.
Original PR description
Description of the issue/feature this PR addresses: Fix AttributeError that occurs during module updates when processing selection field deletions. Current behavior before PR: When updating modules, an `AttributeError` occurs when trying to access the `ondelete` attribute on fields that are not Selection fields: AttributeError: 'Char' object has no attribute 'ondelete' Desired behavior after PR is merged: Add validation to check if the field type is 'selection' or 'reference' before attempting to access field.ondelete as a dictionary. Skip processing for incompatible field types to prevent AttributeError. @moduon MT-13588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247971
A recent test failure was caused by a timing issue in the point-of-sale system. This update adds a brief pause to ensure that all necessary steps are completed before finalizing an order, particularly in scenarios involving local accounting (L10n). This prevents errors related to orders being marked as finalized prematurely.
Original PR description
The `test_point_of_sale_custom_tax_with_extra_product_field` test does a `PaymentScreen.clickInvoiceButton()` and then directly after that a `PaymentScreen.clickValidate()`. In l10n scenarios, the logic behind triggering the `toInvoice` field can take longer. This would cause the validation to execute before the `toggleIsToInvoice` finishes executing and then it would throw an error that the order was already finalized. This PR ads an extra wait on the `Invoice` button to make sure that the toggle is executed properly before finalizing the order. Runbot Error: [233024](https://runbot.odoo.com/odoo/runbot.build.error/233024) Task: [5897371](https://www.odoo.com/odoo/project/1737/tasks/5897371) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248191
This update corrects a reporting issue where refund orders were incorrectly displayed with positive amounts. Now, refund reports accurately show the negative value of the refund, ensuring accurate financial reporting and reconciliation. This change improves the reliability of our point-of-sale data.
Original PR description
Before this commit, the refund orders had positive amount in the report, which is not correct. opw-5821547 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248237
This update fixes a display issue where the kitchen printer incorrectly printed "Order" alongside self-order items and resolves a bug where the 'Send To Kitchen' button remained visible after orders were already processed. The changes ensure accurate order transmission and a smoother user experience for self-order operations.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table (Online Payment)…
Configuration:
-------------------------
- Restaurant Mode
- Self-Order Mode: “QR + Ordering”
- Service At: Table (Online Payment)
--------------------------------------------------------------------------------
Issue 1: Extra Order word print in KOT
---------------------
Steps to Reproduce:
1. Make an order using Self Order (QR).
2. Configure and enable the Kitchen Printer.
3. Check the KOT print it shows “Order Self-Order T2”.
Cause:
- The QWeb template always prefixed “Order” regardless of order type.
Fix:
- Added a condition to skip the “Order” label for self-order references:
--------------------------------------------------------------------------------
Issue 2: “Send To Kitchen” Button Visible even order in kitchen
---------------
Steps to Reproduce:
1. Open the Restaurant
2. Place a order from mobile menu and select a table.
3. In the Restaurant UI:
- Open that table. The "Send To Kitchen" button is still visible even
though the order was already sent to the kitchen and printed.
Cause:
- In self-order mode the order is not automatically synced after being sent to
the kitchen and print.
- As a result, the system still treats it as unsent, leaving the Order button
visible.
Fix:
- Synced the order state after sending it to the kitchen.
----------------------------------------------------
Task-5106704
Forward-Port-Of: odoo/odoo#246867
Forward-Port-Of: odoo/odoo#231005This update fixes an issue where keyboard navigation within the search bar would get stuck, preventing users from moving through other parts of the application. Now, keyboard navigation will correctly move forward from the search bar filter, ensuring a smoother and more intuitive user experience. This resolves a reported usability problem.
Original PR description
When navigating any view using keyboard navigation, the focus gets stuck on the search bar filter and cannot move forward. After this commit keyboard navigation will move forward from the search bar filter. Issue introduced by https://github.com/odoo/odoo/pull/208862 Task-5421313 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243000
This update fixes an issue where the user role wasn't properly set in the Point of Sale system when the 'pos_hr' module wasn't installed. This prevented errors when accessing user roles through the cashier interface, ensuring consistent and reliable functionality. This change improves stability and prevents potential issues related to user permissions within Point of Sale.
Original PR description
When the pos_hr was not installed, the user role was not set, and if the role was accessed with cashier._role, it was undefined. opw-5479742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243057
This update fixes an issue where combo product refunds weren't correctly handling orderlines with quantities exceeding the combo's total. Now, the POS accurately refunds the full quantity of each item within a combo, regardless of the individual orderline quantities. This ensures accurate refunds for complex combo orders.
Original PR description
When refunding a combo item, the 'To Refund' text would always show the same quantity for all the orerlines as for the combo. But combos could have orderlines with a higher quantity than the combo itself (i.e. 3 menus with 2 burgers each - 6 burgers in total. Now the POS would only let us refund up to the limit qty of the combo, so 3 instead of all 6 burgers) After the fix, we check the quantity of each line in the combo and we refund the full quantity (i.e. if you have a 3 menus with 2 burgers each - 6 burgers in total. The burgers will be divided per combo, so each menu refund will automatically refund 2 burgers.) Task-[5503962](https://www.odoo.com/odoo/project/1737/tasks/5503962) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244702
This update resolves an issue that occurred when users attempted to onboard ZATCA journals without a company street address. The fix corrects a data type error that prevented the system from processing OTP requests. This ensures smoother operation for users utilizing the l10n_sa_edi module.
Original PR description
This error occurs when attempting to set the "OTP" received from "ZATCA". Steps to reproduce: - Install `l10n_sa_edi` module > Switch to `SA Company` - Go to `SA Company` and remove `Street` - Journals > Open journal with type 'Sale' > ZATCA > Onboard Journal > Enter any OTP > Request Traceback: `TypeError- value argument must be a str` At [1], the error occurs because the company has an empty street field, causing the value argument to be a `boolean` instead of the expected `string`. [1]- https://github.com/odoo/odoo/blob/40a0b44231fd9a725ccf3667c4992e691e24cde7/addons/l10n_sa_edi/models/certificate.py#L71 sentry-7185302332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248035 Forward-Port-Of: odoo/odoo#243525
This update corrects a technical issue in our Latin American Point of Sale (POS) localization modules (ar_pos, pe_pos) that prevented new features from loading correctly. The fix ensures that all localization modules, including those used with other Odoo modules, function as expected. This resolves a potential compatibility problem.
Original PR description
Problem: - In the `l10n_ar_pos` and `l10n_pe_pos` modules, the `_load_pos_data_fields` method of the `l10n_latam.identification.type` model was missing a `super()` call. - Due to the missing…
Problem: - In the `l10n_ar_pos` and `l10n_pe_pos` modules, the `_load_pos_data_fields` method of the `l10n_latam.identification.type` model was missing a `super()` call. - Due to the missing `super()`, the method chain was broken, preventing other modules extending the same method from being executed. - This issue affected `l10n_gt_edi_pos` when installed together with these modules (see related PR). Context: - The issue was not faced earlier because existing localizations extending this method were loading the same field `name`, so the missing `super()` did not cause functional differences and tests continued to pass. - The problem became visible when `l10n_gt_edi_pos` needed to load an additional field `country_id`, which was skipped due to the broken method chain. Solution: - Added the missing `super()` calls in both modules to restore proper method chaining. related PR https://github.com/odoo/enterprise/pull/103767 task-4393614 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242985
This update resolves an issue where the rental scheduling feature incorrectly limited the number of products grouped together. Previously, it only considered groups if the number of expanded products was strictly less than a set limit. Now, the system correctly includes all products in the grouping, ensuring accurate rental scheduling for all product quantities. This improves the usability of the rental module.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Create exactly 19 rental products. 2. Go to the rental schedule, and group by products. 3. Observe that all 19 product are used as groups. 4. Create one more product. Total: 20. 5. Go to the rental schedule, and group by products. Issue ----- Only the products with actual order line linked to them are used as groups, even if there isn't more products than the hard limit set on the gantt view (`sale_renting.sale_order_line_gantt_schedule`). Cause ----- In d5a6e97abab04282c7a69093cd790b539a958241, the expanded groups are taken into account only if `len(expand_groups) < limit`. However, this should be a less than _or equal_ condition. https://github.com/odoo/odoo/blob/d5a6e97abab04282c7a69093cd790b539a958241/addons/web/models/models.py#L345-L349 Solution -------- Use `<=` as the condition. opw-5887837 Forward-Port-Of: odoo/odoo#248001
This update corrects a validation error that appeared when users deleted all content blocks from a product description. The issue stemmed from leftover whitespace in the HTML structure, which triggered an 'empty document' notification. The fix ensures that empty elements are cleaned up after content removal, preventing this error and maintaining proper product description formatting.
Original PR description
Steps to reproduce: =================== 1- Go to Website > eCommerce > Products 2- Open any product and click "Edit website" 3- Add a lot of content blocks (contact form etc..) & save 4- In the…
Steps to reproduce: =================== 1- Go to Website > eCommerce > Products 2- Open any product and click "Edit website" 3- Add a lot of content blocks (contact form etc..) & save 4- In the product description, delete all content blocks and keep the last one 5- Click Save ->"Document is empty" validation error appears Cause: ====== When saving an HTML field after deleting all content, whitespace text nodes (like newlines) may remain in the DOM element. The _copy_custom_snippet_translations lang_value might have this whitespace as the content, which will cause "Document is empty" error when the content is parsed by fromstring(). This didn't occur before the migration because the previous implementation called _onSnippetRemoved after a content block was deleted, and that handler removed any empty elements. https://github.com/odoo/odoo/blob/8d66c79ecf74900af1c5b003723363be3d52cbc8/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L1370 Solution: ========= After removing the content block, we should also do a cleanup. opw-5263743 Forward-Port-Of: odoo/odoo#241291
This update fixes a potential issue with how Odoo handles translations, specifically when translating fields. Previously, Odoo could sometimes receive translation values with inconsistent numbers of terms, leading to display problems. This change ensures that Odoo always checks for the correct number of translations, resulting in more accurate and reliable translations across the system.
Original PR description
Add missing ``check_translations`` context when translating fields. This prevents fetching dalay translation values that may have a different number of terms and cause inconsistencies. 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#248223
This update fixes an issue where the barcode scanning process wasn't correctly creating quality checks for products tracked by lot. The change ensures that each unique lot within a receipt generates a separate quality check point, improving inventory accuracy and quality control. This ensures that all products are properly assessed when using the barcode scanning feature.
Original PR description
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking…
**Steps to reproduce:** * Install the `stock_barcode`, `quality_control` modules. * Go to *Inventory > Configuration > Settings* and enable **Packages**. * Create a product with **By Lot** tracking enabled and set a barcode reference. * Create a quality control point for this product with following configuration: * Operation: *Receipts* * Control per: *Quantity* * Control Frequency: *All* * Product: the previously created lot-tracked product. * Create a receipt for this product with a quantity of 6 and `mark as todo`. * Open the *Barcode* app and process the receipt. * Scan the product barcode. * Scan some quantity of the product with lot *LOT01* and put those units into a package(Put-In-Pack). * Scan the remaining quantity with lot *LOT02* and put those units into a different package(Put-In-Pack). * Click on **Quality Checks**. **Observed behavior:** * Only one quality check is created, even though the receipt contains two different lots that should each generate a quality check. **Cause:** * In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is equal to quantity(Demand). * During the `write` operation, quality checks are created only for move lines that are not picked, which prevents creating a quality check for each lot. * Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71 **Fix:** * Ensure that quality check points are generated correctly when validating products through the Barcode app using the Put in Pack option. --- opw-5405221 Forward-Port-Of: odoo/enterprise#105930 Forward-Port-Of: odoo/enterprise#102714
A technical error in the Chinese (zh_CN) language installation for the account_reports module was causing installation problems. This update manually corrected a corrupted PO file, resolving the issue and ensuring proper localization functionality for Chinese users.
Original PR description
Currently error is occurs when the user tries to install the`Chinese (zh_CN)` language after installing the `account_reports` module. Error: `Syntax error in po file (line 430): unescaped double quote found` This issue is caused by a bug in Weblate that incorrectly escapes quotation marks (\"). As a result, the PO file becomes corrupt because the quotation mark that should terminate the string is improperly escaped. This commit resolves the issue described above by manually correcting the affected PO file. sentry-6976676644
This update resolves a problem where the ICP report generation failed due to a missing link between return types and the ICP report. The fix now searches for VAT report returns instead, ensuring the report generation process completes successfully. This improves the reliability of the ICP report for Dutch businesses.
Original PR description
Since no return type has a link to ICP report, the tax return check will fail each time. This commit changes this by looking for VAT report returns. opw-5491728 Forward-Port-Of: odoo/enterprise#106955
This update fixes an issue where a distracting helper message was displayed in the bank reconciliation journal when there were no entries. The change hides this message, creating a cleaner and more user-friendly experience, particularly on mobile devices. This improves the overall usability of the accounting module.
Original PR description
Before this commit, in the bank reconciliation journal, the no-content helper remained visible when the quick-create view was opened and there were 0 entries. This was unexpected behavior and caused overlapping issues, especially on mobile views. With this commit, the no-content helper is hidden whenever the quick-create view is open and there are 0 entries. task-5470591
This update fixes an issue where the Odoo bot was incorrectly linked to statement lines when the partner name was 'ODOO'. This ensured accurate reporting and data processing for OdooBot, preventing potential misinterpretations of financial information. The change improves the reliability of the bot's functionality.
Original PR description
When the partner_name was "ODOO" the retrieve partner was linking the statement line to OdooBot. no task id Forward-Port-Of: odoo/enterprise#106933 Forward-Port-Of: odoo/enterprise#106879
A technical issue causing errors when sending monthly tax returns to HMRC has been resolved. The fix addresses a problem where timezone information was incorrectly being passed between the JavaScript and Python components, leading to a traceback. This ensures accurate tax return submissions.
Original PR description
**STEP TO REPRODUCE** 1. Install l10n_uk_reports_cis. 2. Setup hmrc test environment. 3. Try Sending the a monthly tax return to hmrc. 4. You'll have a traceback of the form `expecting only datetimes with no timezone: '2025-12-05T00:00:00.000+01:00' ` **CAUSE** The send button for monthly return is a js widget, which get data from the monthly_return_wizard models and then pass it to `action_send_montlhy_return`. It creates a Luxon datetime in the js for date_from date_to, with a timezone. When the dates are passed back to the python, the still contains the timezone which leads to the traceback. opw-5783030 Forward-Port-Of: odoo/enterprise#106952
A test for the Shiprocket delivery module failed due to a default pricelist being applied, which incorrectly calculated the total order amount. This fix ensures that the test accurately reflects the expected calculation by forcing an empty pricelist during testing, resolving the discrepancy.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692
Forward-Port-Of: odoo/enterprise#105180This update corrects a bug in the task scheduling feature. Previously, tasks started on specific dates would incorrectly limit their duration, resulting in shorter allocated times. The fix ensures tasks automatically extend to cover the full required hours, even when spanning multiple days, improving scheduling accuracy.
Original PR description
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result,…
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours. Source: When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28). However, these four days are not enough to cover 40 hours. The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December. Solution: Remove already-used intervals before recomputing the schedule. opw-5364327 Forward-Port-Of: odoo/enterprise#107043 Forward-Port-Of: odoo/enterprise#101262
This update resolves an issue where duplicate GS1 serial/lot numbers could cause incorrect stock lot queries. The fix ensures that lot names are correctly processed, regardless of whether the 'stock_barcode' app is installed, preventing inaccurate data retrieval.
Original PR description
## Issue When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern. ## Fix The fix related to this…
## Issue When using the *Default GS1 Nomenclature*, it is possible to create multiple lot/serial numbers with a same name if the name matches a barcode rule pattern. ## Fix The fix related to this commit is introduced by [this PR](https://github.com/odoo/odoo/pull/244427). ## Problematic flow The problematic flow starts in the `StockLot._check_unique_lot` method when calling `self._read_group`. At that point, the domain is still correct: it contains the product_id and the (correct) name for the lot we try to create. https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/stock/models/stock_lot.py#L104-L111 In the `BaseModel._read_group` method, the query is defined by the `self._search` method. At that point, the domain is the same as in the previous step, so it is still correct. https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/odoo/orm/models.py#L1902-L1904 Now the flow differs depending on whether the `stock_barcode` app is installed or not. If it is, the `stock_barcode/StockLot._search` method is called: https://github.com/odoo/enterprise/blob/24fea3814b95144953fb809d10bf6a62906c06fd/stock_barcode/models/stock_lot.py#L11-L15 This is the method that calls the `BarcodeNomenclature._preprocess_gs1_search_args` which uses the `skip_preprocess_gs1` context flag: https://github.com/odoo/odoo/blob/b51c80a4368b99e55073856061113244b16b23f9/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L149-L151 **This flow makes the query returned by `self._search(domain)` erroneous, as the start of the name of the lot is removed further down the execution of the `preprocess_gs1_search_args` method.** ### If stock_barcode is not installed The `self._search` method called in the BaseModel will not call `stock_barcode/StockLot._search`, but instead it calls `BaseModel._search`. This totally skips the problematic gs1 flow. opw-5477003 Forward-Port-Of: odoo/enterprise#104720
This update resolves a bug where incorrect product quantities were sometimes sent to the kitchen display when using the numpad in the POS. The fix ensures the system waits for quantity updates before submitting orders, preventing errors in order transmission and improving order accuracy. This resolves a failing test and ensures reliable POS operations.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We are waiting for the orderline to be updated with the correct quantity before submitting the order. X-original-commit: 5ebd1ca99dddbbc62aff90202491562114c0c0dc Forward-Port-Of: odoo/enterprise#106600
1 change
Resolved issues and error corrections
This update fixes an issue where the system incorrectly linked bank statement lines to the 'ODOO' partner. The change ensures that statement lines are now correctly associated with the appropriate partner, improving data accuracy and reporting. This resolves a potential error in how the Odoo bot was retrieving partner information.
Original PR description
When the partner_name was "ODOO" the retrieve partner was linking the statement line to OdooBot. no task id Forward-Port-Of: odoo/enterprise#106879
17 changes
Resolved issues and error corrections
This update replaces the SFU (Server Fast Update) bundle with the latest version (v1.3.3). This ensures Odoo continues to operate efficiently and reliably by addressing potential performance issues and incorporating the newest features from the SFU project.
Original PR description
https://github.com/odoo/sfu/releases/tag/v1.3.3 Forward-Port-Of: odoo/odoo#246979 Forward-Port-Of: odoo/odoo#244971
This update resolves an issue that occurred when users attempted to process ZATCA OTP requests with an 'SA Company' setup where the company's street address was not entered. The fix corrects a data type error, ensuring the system correctly handles missing street information and prevents a crash.
Original PR description
This error occurs when attempting to set the "OTP" received from "ZATCA". Steps to reproduce: - Install `l10n_sa_edi` module > Switch to `SA Company` - Go to `SA Company` and remove `Street` - Journals > Open journal with type 'Sale' > ZATCA > Onboard Journal > Enter any OTP > Request Traceback: `TypeError- value argument must be a str` At [1], the error occurs because the company has an empty street field, causing the value argument to be a `boolean` instead of the expected `string`. [1]- https://github.com/odoo/odoo/blob/40a0b44231fd9a725ccf3667c4992e691e24cde7/addons/l10n_sa_edi/models/certificate.py#L71 sentry-7185302332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243525
This update resolves a potential error that could occur when loading images in the Odoo system. The change ensures the system waits longer for image updates, preventing a sporadic issue caused by encoding delays. This improves the reliability of image display for users.
Original PR description
Encoding the data to base64 can take some times. Before this commit we used this code: ```js await runAllTimers(); await animationFrame(); ``` Now we explicitly wait for the change to happen as awaiting an animation frame can't be enough. runbot-error-237568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248166
This update fixes an error that occurred in the Point of Sale module when a unit of measure (like 'Pack of 6') was deleted. The POS module relies on these UoM records, and without them, it couldn't properly load. This ensures the POS module functions correctly even after users manage their unit of measure settings.
Original PR description
Currently, an error is produced when loading the pos module when a referenced UoM record (e.g., Pack of 6) has been deleted by the user.
**Steps to Reproduce:**
- Install Sales Module.
- Enable **"Units of Measure & Packaging"**.
- Delete the **"Pack of 6"** Units.
- Install POS.
**Error:**
```
ParseError:
while parsing /home/odoo/src/odoo/saas-19.1/addons/point_of_sale/data/point_of_sale_data.xml:38, somewhere inside <record id="uom.product_uom_pack_6" model="uom.uom">
<field name="is_pos_groupable">True</field>
</record>
Exception:
Cannot update missing record 'uom.product_uom_pack_6'
```
The POS module overrides `uom.product_uom_*` records. If the original UoM record has been deleted, the override fails because the record no longer exists.
sentry-7237815280
Forward-Port-Of: odoo/odoo#246940This update resolves a bug that prevented users from sending invoices via PEPPOL, resulting in a 'You cannot remove parts of the audit trail' error. The fix ensures attachments are correctly handled during the PEPPOL invoice sending process, allowing invoices to be sent without interruption. This improves the reliability of the PEPPOL integration for our business customers.
Original PR description
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an…
**Steps to reproduce:** - Install Accounting - Install a localization using PEPPOL (e.g. l10n_be) - Switch to a Belgian company - In Accounting settings, activate PEPPOL and Audit Trail - Create an invoice: * Customer: [a Belgian customer with VAT] * Invoice Lines: [a line with a tax] - Confirm the invoice - Send the invoice via PEPPOL **Issue:** A UserError is raised: "You cannot remove parts of the audit trail.". **Cause:** The audit trail prevent modifying an attachment. When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment. During the process, "res_model" and "res_id" fields of the attachments are set to the message record. Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error. However, it fails because the value is still in cache. **Solution:** Invalidate these fields as it is done when sending the invoice without PEPPOL. https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20 opw-5916696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248220 Forward-Port-Of: odoo/odoo#247949
This update corrects a bug in the self-order mobile experience where the 'Send To Kitchen' button remained visible after an order had already been processed. The fix ensures the system accurately reflects the order's status, preventing unnecessary button displays and improving the user flow. This enhances the efficiency of kitchen staff.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table Issue : “Send To Kitchen” Button Visible even order in kitchen --------------- Steps to Reproduce: 1. Open the Restaurant 2. Place a order from mobile menu and select a table. 3. In the Restaurant UI: - Open that table. The "Send To Kitchen" button is still visible even though the order was already sent to the kitchen and printed. Cause: - In self-order mode the order is not automatically synced after being sent to the kitchen and print. - As a result, the system still treats it as unsent, leaving the Order button visible. Fix: - Added getLastOrderPreparationChange() method to extract current order state and send it with the RPC request after order is saved, ensuring last_order_preparation_change updated Task-5106704 Related PR-https://github.com/odoo/enterprise/pull/106979
This update fixes a bug where combo product prices weren't accurately calculated when a combo included no free items. The change ensures that the total price of combo products is now correctly computed, improving the accuracy of sales reporting and customer billing. This resolves an issue reported in opw-5241225.
Original PR description
If a combo product is configured with no free item, the parent product's price was not computed in total correctly. opw-5241225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing custom JavaScript code added to the website from functioning properly. A recent change in how Odoo handles JavaScript files meant the system no longer recognized custom scripts, leading to errors. This fix ensures that custom JavaScript modifications are correctly applied to the website.
Original PR description
[FIX] website: enable custom javascript on website Steps to reproduce the problem: - Go to the "HTML/ CSS Editor". - Go to the JS tab. - Uncomment the example and save. -> Problem: the confirmation…
[FIX] website: enable custom javascript on website Steps to reproduce the problem: - Go to the "HTML/ CSS Editor". - Go to the JS tab. - Uncomment the example and save. -> Problem: the confirmation dialog does not appear. The problem is that since [1], `/* @odoo-module */` has been removed from the file as since [2], js files in `/static/src` and `/static/tests` are considered as odoo module without the need of the annotation `odoo-module`. In order to understand the problem, here is a summary of what happens when a custom js code is saved; - An attachment is created with the custom js code. - An asset is created to replace the user custom rules of `user_custom_javascript.js` by the one of the newly created attachment. Because the url of the newly created attachment looks like `/_custom/web.assets_frontend_lazy/website/static/src/js/user_custom_javascript.js`, the transpiler does not recognize it as an odoo module. task-5925607 [1]: https://github.com/odoo/odoo/commit/6d2fda172ec9cc7642abe9625ca486c7769e8297 [2]: https://github.com/odoo/odoo/commit/5f2c505836002ac7851c29c28d612f721d467bc4 Forward-Port-Of: odoo/odoo#247959
This update prevents the deletion of attachments when removing them from email templates. Previously, removing an attachment from the mail composer would permanently remove it from all future emails. The fix ensures attachments remain associated with templates, maintaining consistent email content.
Original PR description
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by…
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by Email". 5. In the mail composer, remove the template attachment **Issue:** - The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails. **Cause:** - The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment. **Solution:** 1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server. 2. In `onFileRemove`, check the `res_model` of the attachment. 3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink) and only remove it from the composer view. opw-5163679 Forward-Port-Of: odoo/odoo#245886 Forward-Port-Of: odoo/odoo#238692
This update resolves a technical issue that caused Odoo module updates to fail with an error when encountering certain field types. The fix adds a check to ensure only 'selection' and 'reference' fields are processed, preventing crashes and ensuring smoother updates. This improves stability and reliability during module updates.
Original PR description
Description of the issue/feature this PR addresses: Fix AttributeError that occurs during module updates when processing selection field deletions. Current behavior before PR: When updating modules, an `AttributeError` occurs when trying to access the `ondelete` attribute on fields that are not Selection fields: AttributeError: 'Char' object has no attribute 'ondelete' Desired behavior after PR is merged: Add validation to check if the field type is 'selection' or 'reference' before attempting to access field.ondelete as a dictionary. Skip processing for incompatible field types to prevent AttributeError. @moduon MT-13588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247971
This update resolves a test error that was causing orders to be incorrectly marked as finalized in certain accounting scenarios. The fix adds a brief delay to ensure all order processing steps are completed before validation, preventing the 'already finalized' error. This ensures consistent order handling.
Original PR description
The `test_point_of_sale_custom_tax_with_extra_product_field` test does a `PaymentScreen.clickInvoiceButton()` and then directly after that a `PaymentScreen.clickValidate()`. In l10n scenarios, the logic behind triggering the `toInvoice` field can take longer. This would cause the validation to execute before the `toggleIsToInvoice` finishes executing and then it would throw an error that the order was already finalized. This PR ads an extra wait on the `Invoice` button to make sure that the toggle is executed properly before finalizing the order. Runbot Error: [233024](https://runbot.odoo.com/odoo/runbot.build.error/233024) Task: [5897371](https://www.odoo.com/odoo/project/1737/tasks/5897371) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248191
This update ensures that pricelists correctly apply to event products within the Point of Sale (PoS) system. Previously, event products weren't recognizing pricelists, leading to incorrect pricing. This fix resolves this issue, guaranteeing accurate pricing for event tickets during PoS transactions.
Original PR description
Before this fix, pricelist didn't take effect on event products. How to reproduce : 1. Create a pricelist with fixed price and make it available for a pos. 2. Open a pos with event products. 3. Make an orderline with an event product 4. Apply a pricelist on it. The solution is to override setPricelist() in pos_event. Which is called when we apply a pricelist to an order. task: 5092613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where the self-order page would freeze if local data was corrupted. Now, users receive an error message and can easily clear their data and refresh, particularly helpful on mobile devices. This enhances usability and prevents frustrating downtime.
Original PR description
Inconsistent data in the localDB or local storage can cause the pos_self_rder to fail before it can get initialized. When this happens the page just stays white. Now when an error happens while initializing an error message will show up and give the user the option to clear all local data and refresh the page. This should be especially useful for users on mobile where it's a pain to refresh the local data manually. Task-[5420544](https://www.odoo.com/odoo/project/1737/tasks/5420544) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246925
This update resolves an issue where the website's redirection process was losing URL parameters, causing errors and incorrect behavior. The fix ensures that all parameters are properly encoded during redirection, maintaining data integrity and preventing errors when users interact with the website.
Original PR description
Scenario from 17.0:
- set domain on website
- go to website /website/force/1?path=%2F%3Fa%3Db%26c%3Dd with another
domain
=> you are redirected to {domain}/?a=b instead of {domain}/?a=b&c=d
Scenario from 18.0:
- set domain on website
- go to /appointment/1 on other domain, select person date and time
- click on "Editor"
=> you get error:
> TypeError: AppointmentController.appointment_type_id_form() missing 1
> required positional argument: 'duration'
Cause: the /website/force/ domain redirection doesn't encode the
parameter when redirecting, so we lose parameters after the first one.
Fix: encode parameters when redirecting domain in /website/force/ route.
opw-5441957
Forward-Port-Of: odoo/odoo#247679
Forward-Port-Of: odoo/odoo#242252This update corrects a bug where loyalty points were incorrectly calculated and duplicated after saving a POS order, particularly when adding products. The fix ensures that loyalty points are accurately reflected, preventing over-rewarding of customers. This improves the reliability of the loyalty program within the Point of Sale system.
Original PR description
Step to reproduce: - have a trusted pos and a loyalty program which gives points per $ spent - start pos and select order and a partner (he should already have some LPs) - notice the loyalty points…
Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order
Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50, product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250
Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state
Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
opw-5609964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248077
Forward-Port-Of: odoo/odoo#245400This update resolves a rare issue where the popover animation in tests finished too quickly, leading to additional steps and test instability. By adjusting the animation timing, this fix ensures tests run reliably and consistently, improving overall software quality. This change focuses on internal test stability.
Original PR description
Because the popover had his animation enabled in tests, it could in very rare occasion end too fast and call it's finished callback, triggering extra repositionning (and thus extra expect.steps). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247341 Forward-Port-Of: odoo/odoo#244491
This update fixes an issue where the duration of quick-created calendar events wasn't accurately reflected after manual adjustments. The change ensures that the displayed duration always matches the intended length, improving event management accuracy. This aligns with previous versions of Odoo.
Original PR description
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag…
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag on the calendar to create a `2-hour` time slot (quick-create popup opens). - Manually adjust the start or end time to make the event `3 hours` long. - Click `Save & Close`. - Click on the event: it correctly displays (3 hours). - Click `Edit` and observe the `Duration` value. **Observation:** The duration field shows 2 hours instead of 3 hours. **Root cause:** - The `duration` field is not available (and therefore not stored) in the `quick-create view` at [1]. - When the `stop` time is set manually, the `duration` is computed at [2]. - When the `start` time is changed, the `stop` time is computed based on the previously computed `duration` at [3]. **Fix:** This commit adds the `duration` field to the `quick-create` view as `invisible` (preventing it from being recomputed on each onchange) and `force_save`. This aligns the behavior with `19.0` by preserving the last computed duration in the front-end model, as implemented in PR [4]. [1]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/views/calendar_views.xml#L294-L339 [2]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L353-L356 [3]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L358-L374 [4]: https://github.com/odoo/odoo/pull/226909 opw-5867946 Forward-Port-Of: odoo/odoo#247193
2 changes
Resolved issues and error corrections
This update resolves two errors impacting Hong Kong payroll reporting. Specifically, it corrects a calculation mistake that incorrectly deducted ERMPF from taxable salaries and ensures that rental allowances are not included in IRD reports, aligning with Hong Kong's specifications. This ensures accurate tax reporting and compliance.
Original PR description
Fixes two issues related to computations; The taxable salary wrongly deduce the ERMPF which it should not. in the IRD reports, the total income includes the rental allowances, which is wrong according to their specs. task-5353781 Forward-Port-Of: odoo/enterprise#100842
A test for the Shiprocket delivery module was failing due to a default pricelist being applied, which incorrectly calculated taxes. This fix ensures that the pricelist is cleared during testing, allowing for accurate tax calculations and reliable test results. This resolves a discrepancy in the reported order total.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692
Forward-Port-Of: odoo/enterprise#1051803 changes
Resolved issues and error corrections
This update fixes an issue where month names were being displayed using the user's locale instead of the Odoo environment's language. This ensures that month names are consistently shown in the correct language for each user, improving accuracy and user experience. The fix impacts several payroll and reporting modules.
Original PR description
Month name is using the locale language instead of the env language Get month name in the env language Community PR: odoo/odoo#246790 Task [link](https://www.odoo.com/odoo/project.task/5902364) task-5902364 Forward-Port-Of: odoo/enterprise#107087 Forward-Port-Of: odoo/enterprise#106175
This update resolves an error that prevented users from correctly selecting rental product dates. Specifically, when the start and end dates were the same, a technical error occurred. The fix ensures a user-friendly error message is displayed, preventing the issue and allowing rentals to be processed correctly.
Original PR description
Currently, an error occurs when selecting a date on a rental product. **Steps to Reproduce:** - Install the `website_sale_stock_renting` module. - Go to `Products` and create a product with the…
Currently, an error occurs when selecting a date on a rental product. **Steps to Reproduce:** - Install the `website_sale_stock_renting` module. - Go to `Products` and create a product with the following `configuration`: - Enable `Track Inventory` and set `Quantity On Hand` greater than zero. - Disable `Sell when Out-of-Stock` under the `eCommerce tab`. - Under the `Sales tab`, set `Periodicity to Days`, and set the same time for `Pickup and Return`. - Go to `Website > Shop`. - Open the product, select the same date for both `Start Date and End Date`, and `click anywhere`. `ValueError: min() iterable argument is empty` **Cause:** - This error occurs because when the start and end dates are the same, the method returns a set of dates from here [1]. Since there is only a single date, the loop is not executed and it returns an empty list of availabilities [2], which then raises the error [3]. - The error happens due to the removal of this condition [4] in this [recent commit]. - The warning message is now handled here [5]. **Fix:** - This commit ensures that when a user selects a start date that is greater than or equal to the end date, a UserError is raised and the proper warning message is displayed. [1]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/sale_stock_renting/models/sale_order_line.py#L616 [2]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/product_product.py#L77 [3]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_stock_renting/models/website.py#L18-L22 [4]: https://github.com/odoo/enterprise/blob/66f144df6f2056212797547dfef5ed58232698cd/website_sale_renting/models/product_template.py#L175-L176 [5]: https://github.com/odoo/enterprise/blob/f26da0d5285ff47bf7a4297141830db67f7103d1/website_sale_renting/static/src/interactions/daterange_picker.js#L213 [recent commit]: https://github.com/odoo/enterprise/commit/4afdc272e5a7fc4284bbd9f97283b8ec0aa28c34 sentry-7243018656 Forward-Port-Of: odoo/enterprise#106602
A recent issue was causing nightly automated tests to fail due to unexpected errors in the system. This update addresses a problem where test configurations were incorrectly overriding internal functions, leading to crashes. The fix adds a check to ensure these functions are properly set before execution, improving test reliability and stability.
Original PR description
Before this commit, in the `TestInvitation` class mocked by VOIP tests, it was possible to override some inner functions by giving undefined values in `receiveInvite`. This caused the code to crash when it tried to call these undefined values. This commit fixes this issue by adding a sanity check before calling these methods to ensure they have been set.
6 changes
Resolved issues and error corrections
This update fixes an issue where tasks auto-planned with specific start dates were incorrectly limited to shorter durations. The system was re-using previously scheduled intervals, preventing tasks from extending into the following month. The fix ensures tasks accurately calculate and schedule the required hours, avoiding scheduling errors.
Original PR description
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result,…
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours. Source: When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28). However, these four days are not enough to cover 40 hours. The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December. Solution: Remove already-used intervals before recomputing the schedule. opw-5364327 Forward-Port-Of: odoo/enterprise#106160 Forward-Port-Of: odoo/enterprise#101262
This update fixes an issue where refunds with global discounts were incorrectly flagged as exceeding the original order total. The change ensures that refunds accurately account for reversed discounts, preventing inaccurate reporting and improving the reliability of refund processing. This impacts the accuracy of financial reporting related to refunds.
Original PR description
Before this commit, when refunding an order with global discounts, the refund total was compared against the original order total without considering the discounts. While the reversed discount line would be added to the refund, the system could incorrectly flag the refund as exceeding the original order total. opw-5492686
This update resolves a runbot test failure caused by the automatic installation of the SEPA module during chart of account loading. The fix disables automatic module installation during testing to prevent database modifications, ensuring consistent and reliable test results.
Original PR description
**PROBLEM** https://github.com/odoo/enterprise/pull/106033 PR above fixes the auto install of the sepa module when loading a chart of account of some country. However, installing modules during tests is not allowed (it commits real transaction to the db). It didn't occur during the "daily" runbot because they start the tests with all modules installed (sepa module included). **REPRO STEPS** 1. On a db without the sepa module installed, run the test function .test_bank_account_code_prefix (in account module). 2. The test will fail because it load a chart of account and then try to install the sepa module. **FIX** Deactivate the auto install when running tests. runbot-238921
This update fixes a bug in the Saudi HR payroll system where employees resigning after less than two years received a negative end-of-service benefit calculation. The code has been updated to correctly set this value to zero, aligning with Saudi accounting rules. The change also improves clarity by moving the relevant salary logic directly into the rule definition.
Original PR description
purpose: In the saudi eos rule, if the employee resigned after working in the company less than 2 years, their end of service is being computed as a negative value when it should be 0 instead. - added the correct check for the case of employee resignation - moved the logic of the salary rules for EOS benefit and provision from python methods to the rule itself to be more clear for the user task-id: 5499646
This update ensures Odoo's Spanish tax reporting (l10n_es_report) complies with the latest requirements from BOE (the Spanish Official Gazette). Specifically, it incorporates changes related to Modelo 347, adding a placeholder for subsidy numbers and ensuring accurate export data for tax reporting purposes.
Original PR description
reference: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-25390 considering the modelo 347 As we do not have anything for the subsidy number, we just put 6 0s. opw-5926624 Forward-Port-Of: odoo/enterprise#107125
A test for the Shiprocket delivery module failed due to a default pricelist being applied, incorrectly overriding tax calculations. This change forces an empty pricelist during testing, ensuring accurate tax calculations and resolving the test failure. This improves the reliability of the Shiprocket delivery module tests.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692
Forward-Port-Of: odoo/enterprise#10518017 changes
Resolved issues and error corrections
This update fixes an issue where the static file box in the HTML editor was unintentionally editable, causing confusing keyboard navigation. The change now prevents automatic editing, ensuring a smoother and more predictable user experience when working with files within the editor. This improves overall usability.
Original PR description
### Purpose of this PR: - In the static file box, the file name is contenteditable by default, which leads to unexpected caret movement and arrow-key navigation behavior. - Change the behavior so that the file name is contenteditable="false" by default and becomes editable only when the user explicitly clicks on it. The editability is reverted when clicking outside of the file name. - This ensures consistent keyboard navigation while keeping the change limited to the static file box. task-5427329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that pickings are automatically created when validating POS orders linked to sale orders, especially when inventory management creates pickings at the end of a session. Previously, stock levels weren't updated correctly. This change improves the accuracy of stock tracking for POS sales.
Original PR description
Before this commit, when validating a POS order linked to a sale order, if the Inventory Management was configured to create pickings at the end of the session, no picking was created for the order, and the sale order stock was not updated. This commit fixes this issue by ensuring that the picking is created for the imported sale orders in real time. opw-5423113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restricts access to cost and margin information within the Point of Sale (PoS) system. Previously, this sensitive data was visible to all users, regardless of their permissions. Now, the 'Show margins & costs' setting controls visibility, ensuring only employees with 'advanced' cashier rights can see this information.
Original PR description
Before this commit, the "Show margins & costs" setting did not correctly enforce visibility. When enabled, cost and margin information was displayed to all users, regardless of their cashier rights. Furthermore, even when this setting was disabled, this sensitive information was still visible to cashiers with advanced and minimal rights. This commit modifies the behavior: - If "Show margins & costs" is enabled, cost and margin details are visible in the PoS UI only for employees with 'advanced' cashier rights, and hidden from those with 'basic' rights. - If "Show margins & costs" is not checked, this information is hidden from all users in the PoS UI. opw-4899231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures website controller pages are correctly linked to relevant business models, resolving previous errors caused by incorrectly binding them to transient or abstract models. This improves data accuracy and stability within the website functionality.
Original PR description
Before this commit, a website_controller_page could be bound to any sort of model. For some of them this was irrelevant or plain wrong: - transient models: they are not pointing to anything relevant business wise - abstract: they cannot even have records, and most of them are mixin - _auto = False: Those are models with a table which is a custom one. The heuristics here is to say that records are not "real" ones. Also, most of these tables are sqlViews or something similar Business wise there were errors because of this, so this commit introduces a constraint that forbids the above use cases. sentry-6842596566 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Outlook Calendar was displaying raw HTML tags in event descriptions when exporting events. The change adds a new method to correctly format event descriptions for Outlook, ensuring that event details are rendered properly in the calendar application. This improves the user experience when sharing events with Outlook.
Original PR description
****Behavior:**** **Current:** When exporting an event for Outlook Calendar, the file returned is the same as for ICalendar(.ics), however Outlook cannot handle the HTML description of the event when passed through the 'DESCRIPTION:' field which causes the event description to display raw HTML tags. **Solution:** Outlook can use the 'X-ALT-DESC:' field with 'text/html' parameter to handle HTML. A new route was created to generate the event's ics file with the correct parameters for Outlook. ****Steps to reproduce:**** - Go to an event from Website - Select the Outlook icon under 'Add to calendar' - Import the file to Outlook Calendar - You'll notice HTML tags in the description of the event. opw-5116354
This update resolves a bug where translated text couldn't be updated or removed when using highlights on editable pages. The fix ensures that all elements within a translated section are correctly processed, allowing for proper translation editing functionality. This improves the user experience when working with highlighted text in the translation editor.
Original PR description
[FIX] base, tools: fix the behaviour of inline translated elements Steps to reproduce: - Go to a website page (in "Edit" mode) > Add a "Title" snippet. - Select the whole "title" > Set a highlight…
[FIX] base, tools: fix the behaviour of inline translated elements
Steps to reproduce:
- Go to a website page (in "Edit" mode) > Add a "Title" snippet.
- Select the whole "title" > Set a highlight effect on it.
- With the same text selected, transform it to a link and save.
- Try to translate the title into another language in the editor > You
cannot update the text or remove it.
The code from [1] introduced a feature that allows forcing some specific
elements to be "translated inline" using the `o_translate_inline` class.
It was used mainly to handle specific cases where elements DOM is
handled in JS in a way that breaks the "Translate" editor (e.g., text
highlights).
By forcing the highlight `<span/>`s to be inline translated, the fix
from [1] only handled situations where a highlight effect has a non-
"inline-translated" element (e.g., a link) amongst its text content.
E.g. This DOM structure:
```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
Go to the <a href="/contactus">Contact Us</a> page
</span>
```
Which caused the translation `<span/>` to be set inside the highlight
structure [A].
Now, as explained in the steps above, there are some cases like with
this DOM:
```
<span class="o_text_highlight o_text_highlight_wavy o_translate_inline">
<a href="/contactus">Contact Us</a>
</span>
```
That will make the translation code check the inner non-"inline
translated" children even within a `o_translate_inline` parent (see:
`translate_xml_node()` > `hastext()` | `process()`), leading to the
same issue as [A].
The goal of this commit is to prevent any similar situation causing the
translation spans to be added inside elements forced to be translated
as a whole, by automatically considering all elements inside a
`o_translate_inline` parent as inline translated too.
This commit also adds a test for the explained behavior.
[1]: https://github.com/odoo/odoo/commit/e9659e55356e5e4de63f2324eb88a7b6f07cd835
opw-4243639
linked to: opw-3980975
linked to: opw-4089482
linked to: opw-4061566This update corrects a visual glitch in the HTML editor for Firefox, preventing the creation of duplicate buttons and links when adding text. The fix resets the browser's internal state, ensuring proper display and functionality after editing links and text within the HTML editor.
Original PR description
In some situations Firefox behaves strangely when adding a character add the end of a button, by duplicating the button element without children and inserting the text between both buttons. It seems Firefox maintains an internal selection state that is corrupted after some operations. This commit resets the collapsed selection inside links in order to reset this internal state in Firefox. Steps to reproduce: - Insert a link - Put some text after the link - Delete the first character from the text - Keep deleting until the last character from the button is deleted - Type a character => The button was duplicated and the text was inserted between both buttons. - Note that if you undo/redo, then typing a character did work fine task-5033890
This update fixes an issue where the table editor loses focus after deleting rows or columns, disrupting the editing workflow. Now, the editor automatically refocuses, ensuring Undo functionality works correctly and improving the overall user experience when managing tables. This prevents confusion and frustration for users.
Original PR description
**Current behavior before PR:** When a user deletes a row or column from table menu, the editor loses focus. As a result, actions like Undo do not behave as expected and require multiple attempts to restore the original table state. This breaks the editing flow, causes confusion when performing table-related actions. **Desired behavior after PR:** This PR ensures that editable is focused after deleting row or column from table menu. This commit also makes sure that selection is set properly and hint is visible on empty cell after deleting the column. task-5725593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor issue that prevented the application from functioning correctly when using the Ukrainian language. The fix addresses a problem with how the system retrieves language patterns, ensuring a smoother user experience for Ukrainian-speaking users. This change improves overall application stability and reliability.
Original PR description
**Steps to Reproduce:** 1. Install `stock_fleet` module (with demo data). 2. Set the **Ukrainian** language for the user. 3. Open Fleet > Vehicle > Click Category Error: `KeyError: '2'` **Cause:** Babel's CLDR list patterns for some locales (e.g., Ukrainian 'unit-short') do not include the two-item pattern key, so when babel's `format_list` attempts to access patterns, it will raise an error. **Fix:** This commit wraps the call in a try/except that handles KeyError and retries formatting with the 'standard' style to avoid the crash.
This update fixes an issue where Italian tax information (like VAT number) wasn't being properly carried over when creating a company record from an Italian ecommerce order. This ensures accurate reporting and compliance with Italian tax regulations. The change ensures all required Italian tax fields are populated during company creation.
Original PR description
**STEP TO REPRODUCE** 1. Create a ecommerce order on a shop page of a italian company. 2. Goes to the checkout page, enter info (company_name, l10n_it_codice_fiscale, l10n_it_pa_index). 3. On the contact created, click on create company. 4. Notice l10n_it fields are not propagated to the company. opw-5477372 Forward-Port-Of: odoo/odoo#246785
This update corrects a bug in how loyalty rewards are calculated when products are purchased in non-unit UOMs (like dozens). Previously, rewards weren't applied correctly, requiring a large quantity to trigger the discount. This fix ensures that rewards are accurately applied based on the actual quantity purchased, regardless of the unit of measure.
Original PR description
### Issue: Due to this issue, applying a different uom than unit one, will not apply the reward regarding to quantities. #### Steps to reproduce: 1- Create a program: buy 12 get 6 free. 2- Create a SO, add a dozen of product to SOL. 3- Click on reward. Expect: 6 free unit is added. Current outcome: Nothing is added. Unless you add 12 dozens which is going to add 6 units. ### Cause: In checking rules, `product_uom_qty` is directly used without conversion to quantity. Note: `test_different_uom_to_hours_on_sale_order_confirmation` is failing due to this fix, because the uom_id unit/dozens and hours/days are not compatible. As this is not possible in UI, IMO we can delete the breaking SOL in that test. opw-5913638
This update fixes a bug where customers could still redeem expired ewallet points. The change prevents users from claiming points after their expiration date, ensuring accurate point balances and preventing potential revenue loss. This improves the customer experience and maintains data integrity.
Original PR description
### Issue: Due to this issue, ewallet points are claimable after expiry. #### Steps to reproduce: 1- Create a ewallet program, and generate an ewallet for a partner. 2- Set the expiration date in the past. 3- Create a SO with the same partner. 4- Click on reward. Expected: The ewallet shouldn't be claimable. Current outcome: The ewallet is claimable. opw-5476686
This update fixes an issue where the duration of quick-created calendar events wasn't accurately reflected after manual adjustments. The change ensures that the displayed duration always matches the intended event length, improving event management accuracy. This aligns with recent updates in Odoo 19.0.
Original PR description
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag…
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag on the calendar to create a `2-hour` time slot (quick-create popup opens). - Manually adjust the start or end time to make the event `3 hours` long. - Click `Save & Close`. - Click on the event: it correctly displays (3 hours). - Click `Edit` and observe the `Duration` value. **Observation:** The duration field shows 2 hours instead of 3 hours. **Root cause:** - The `duration` field is not available (and therefore not stored) in the `quick-create view` at [1]. - When the `stop` time is set manually, the `duration` is computed at [2]. - When the `start` time is changed, the `stop` time is computed based on the previously computed `duration` at [3]. **Fix:** This commit adds the `duration` field to the `quick-create` view as `invisible` (preventing it from being recomputed on each onchange) and `force_save`. This aligns the behavior with `19.0` by preserving the last computed duration in the front-end model, as implemented in PR [4]. [1]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/views/calendar_views.xml#L294-L339 [2]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L353-L356 [3]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L358-L374 [4]: https://github.com/odoo/odoo/pull/226909 opw-5867946 Forward-Port-Of: odoo/odoo#247193
This update fixes a visual issue where date picker arrows were incorrectly oriented when the website was displayed in RTL (Right-to-Left) languages like Arabic. The fix ensures that date pickers function correctly for all users, regardless of their language settings, improving the overall user experience.
Original PR description
### Steps to reproduce: - Download Rental and eCommerce apps. - Install an RTL language (e.g., Arabic) on the website. - Create a rental and go to website. - Try to pick a date for the rental. ### Issue: When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example): https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76 Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them. ### Solution: The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically. opw-5498615
This update fixes a crash that occurred when creating vendor bills with multiple purchase orders linked through the autocomplete field. The issue stemmed from an error in how Odoo handled record insertion, leading to duplicate key errors. By limiting the number of linked purchase orders, this fix ensures stable bill creation.
Original PR description
Steps to reproduce ================== - Edit the Vendor Bill form view to set a limit of 2 on the invoice_line_ids field. - Create 2 purchase orders with the same vendor and 4 products - Create a vendor bill - Set the same vendor - Using the autocomplete field, select the first purchase order - Save the form - Select the other purchase order in the autocomplete field - Delete the record before the last one => Got duplicate key in t-foreach: datapoint_12 Cause of the issue ================== Before inserting the last 4 lines: `this._currentIds = [1, 2, 3, 4]` After the second insert, we have `this._currentIds = [1, 2, virtual_1, 3, virtual 2, virtual_3, virtual_4, 4]` Only the first record is inserted at the correct place, following ones are off by one. opw-5264594
This update resolves a bug where the total time displayed in the Timesheet list view was incorrectly formatted as a regular number instead of a time. The fix ensures the total is always displayed in the correct time format, even after refreshing the page. This improves the accuracy and usability of the Timesheet reporting feature.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954
This update resolves a minor issue related to the scale certificate checksum. It synchronizes the checksum value with a recent fix implemented in the main Odoo project, ensuring consistent and accurate certificate validation. This change improves the reliability of the l10n_eu_iot_scale_cert module.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248413.
12 changes
Resolved issues and error corrections
This update fixes a visual issue in the Italian tax module where the TC-XX codes for pension funds weren't displayed alongside the fund names. Previously, all other selection fields showed codes first, but this field was an exception. This change ensures consistent and clear presentation of tax information for Italian businesses.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a redundant parameter from the Italian VAT reporting system (l10n_it_edi). The parameter was not being used in the API and caused confusion for developers. This change simplifies the system and improves its stability.
Original PR description
Juyt remove the `recipient_codice_fiscale` parameter for the request to the SdI, as it is not used in the API. It just creates confusion for the people who are debugging.
This update fixes an issue where the duration of quickly created calendar events wasn't accurately reflected after manual adjustments. The change ensures that the displayed event duration always matches the intended length, improving event planning accuracy. This aligns the calendar functionality with recent updates in Odoo 19.
Original PR description
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag…
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag on the calendar to create a `2-hour` time slot (quick-create popup opens). - Manually adjust the start or end time to make the event `3 hours` long. - Click `Save & Close`. - Click on the event: it correctly displays (3 hours). - Click `Edit` and observe the `Duration` value. **Observation:** The duration field shows 2 hours instead of 3 hours. **Root cause:** - The `duration` field is not available (and therefore not stored) in the `quick-create view` at [1]. - When the `stop` time is set manually, the `duration` is computed at [2]. - When the `start` time is changed, the `stop` time is computed based on the previously computed `duration` at [3]. **Fix:** This commit adds the `duration` field to the `quick-create` view as `invisible` (preventing it from being recomputed on each onchange) and `force_save`. This aligns the behavior with `19.0` by preserving the last computed duration in the front-end model, as implemented in PR [4]. [1]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/views/calendar_views.xml#L294-L339 [2]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L353-L356 [3]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L358-L374 [4]: https://github.com/odoo/odoo/pull/226909 opw-5867946
This update resolves an issue where importing EDI invoices could fail when products were restricted to a different company. The fix ensures products are correctly identified during import, preventing 'Incompatible company' errors. This improves the reliability of EDI invoice processing within multi-company Odoo environments.
Original PR description
In a multi-company environment, importing an EDI invoice could fail if a line contains a product restricted to another company. The error "Incompatible company on records" was raised because company consistency rules were applied.
Example steps to reproduce:
- Create two Italian companies, A and B
- In company A, create a product with default code or barcode "TEST"
- This can also occur using the barcode and the “Vendor Product code” from the Purchase supplier.
- Restrict this product to company A
- Create an EDI invoice in company A with this product for company B as customer
- Import the invoice in company B, which would fail
This fix adds a search domain to correctly find products during import
opw-5496912This update fixes an issue where invoices created in foreign currencies didn't accurately display the amount in the company's local currency when generating reports. The fix ensures that amounts are correctly rate-adjusted, providing accurate financial reporting for Saudi Arabia companies. This improves the reliability of financial data.
Original PR description
After 267a876451da8b39ab8c5885e7198ebfeb841573 invoice report will not show the correct amount in company currency Steps to reproduce: - With SA Company setup - Create invoice in foreign currency - Print Issue: Amount in company currency have not been rate adjusted. This occurs because amount_untaxed and amount_total are expressed in foreign currency. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug that occurred when users entered non-numeric values in the 'Number of SN' field during serial/lot number generation. By changing the input field to only accept numbers and adding a check for periods, the system now gracefully handles invalid input, preventing tracebacks and ensuring reliable serial number creation.
Original PR description
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots…
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots wizard, a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`. Steps to Reproduce: ========================= - Install the "stock" module. - Create a receipt for a serial-tracked product. - Open the detailed operations. - Click on "Generate Serials/Lots". - Enter a string value in the "Number of SN" field. Result: A traceback is raised with: InvalidNumberError: `"dhha" is not a correct number.` Cause of the issue: ========================= The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) field is defined as type="text", which allows users to enter string values, even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139). With This Commit: ========================= The input type is changed from type="text" to type="number", ensuring that only numeric values can be entered. This prevents invalid input and avoids the traceback when generating serial or lot numbers. Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`, ensuring that only integer values are allowed.
This update corrects a reporting error in the Spanish VAT (l10n_es) module. Previously, the 'mod 390' report displayed the same vendor bill amount twice. The issue stemmed from an incorrect tax template definition for 0% EU G transactions, now resolved to ensure accurate reporting.
Original PR description
How to reproduce: - Install the l10n_es module - Switch to a spanish company - Confirm a Vendor Bill with a Product with the tax 0% EU G - Go to the Tax Report and select mod390 The problem: In the section "Adquisiciones intracomunitarias de bienes", the total amount is shown two time, once for grid 716 and once for grid 26 Why: In the declaration of the tax template for 0% EU G, there is two tags for the mod 390, the one for grid 26 being wrong Before: <img width="818" height="447" alt="image" src="https://github.com/user-attachments/assets/0565802d-5d98-4e0f-9e08-50776f0a5aec" /> After: <img width="834" height="443" alt="image" src="https://github.com/user-attachments/assets/89696c83-7022-439d-adaa-d456c2dbadf8" /> opw-5867849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing a key website test from running correctly. The test required a specific user group to be enabled, which was only necessary when running with the demo environment. This change ensures the test now works consistently regardless of the environment, improving testing reliability.
Original PR description
Commit f86f6f6a3dc6bbeb8c68308aab2462b9c7bb935d (6th February 2026) added the test test_website_force_domain_redirect but it doesn't work without demo data because it was requiring "website.group_multi_website" group to be enabled. Fix: add the group for the test case in case it's not enabled. runbot-[238897](https://runbot.odoo.com/odoo/runbot.build.error/238897) opw-5441957 Note: this was noticed in saas-18.3 forward port so this is only necessary up to saas-18.2 version.
This update corrects a technical issue where Odoo incorrectly identified nodes with directives (like 'groups') as translatable. This prevented proper translation of certain elements within the user interface. The fix ensures that only elements without directives are considered for translation, improving the accuracy of translated content.
Original PR description
Nodes with directives must not be included inside a translatable span. But the function `translatable` missed the directive `groups` (without `t-`), and the class `o_translate_inline` should only override the predicate about the element's tag.
This update corrects an issue where a proforma vendor bill was incorrectly displayed when accessing or downloading bills through the customer portal. The fix restricts proforma bills to invoices and credit notes, ensuring users receive the correct financial documentation. This improves the accuracy and clarity of billing information for customers.
Original PR description
When accessing to a bill via the portal, we display a proforma vendor bill, same when we download from the portal, it should not be the case Steps: - Create and confirm a vendor bill - Via the menu action, click on "Share" and copy the link - Open the link -> a proforma vendor bill is displayed - Download the bill -> we get a proforma vendor bill Fix: Allow proforma only for invoices/credit notes opw-5882732
This update fixes a restriction in the Zengin file import process, allowing a wider range of characters to be used. Previously, only specific Japanese characters were permitted, leading to import failures. Now, standard ASCII characters like hyphens and alphanumeric text are supported, ensuring all valid Zengin files can be imported correctly.
Original PR description
Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text. This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include: - Uppercase alphanumeric characters (A-Z, 0-9) - Standard symbols (e.g., -, ., /, (, ), etc.) Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite task-5928087
This update fixes an issue where the Accounts Coverage Report incorrectly flagged deprecated accounts as missing. The change removes a filter that excluded inactive accounts, ensuring the report accurately reflects the company's financial data. This improves the report's reliability and accuracy.
Original PR description
Purpose: Accounts Coverage Report considers only active accounts and deprecated accounts are excluded(which should be included).
Steps to reproduce:-
- Switch to company with Belgian COA.
- Open form view of P&L report and click on Accounts Coverage Report.
- Coverage report raises error message that account 667 is reported but does not exist in COA.
- Create an expense account with code 667000 arbitrarily.
- Coverage report does not raises above error.
- Now deprecate 667000 account.
- Coverage report again raises error that account 667 is reported but does not exist in COA.
Solution: remove `('deprecated', '=', False)` from domain.
task- 5906024
Forward-Port-Of: odoo/enterprise#107085