Monday, January 26, 2026
44 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue that occurred when upgrading Odoo with the l10n_id module installed. The migration script was incorrectly creating extra tax lines, leading to errors. This fix ensures a smoother and more reliable upgrade process for users with the l10n_id module.
Original PR description
Encountered an issue during upgrade from v16 with existing l10n_id installed on the DB. The script will try to force create the tax and create extra `repartition_line_ids` which is causing multiple "base" line to be added and trigger the `ValidationError`. Upgrade request: [3442445](https://upgrade.odoo.com/odoo/request/3442445) Upgrade task: [5314508]( https://www.odoo.com/odoo/70/tasks/5314508) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237897
This update resolves a technical issue causing errors when creating multiple companies with Sri Lanka settings. The problem stemmed from duplicate tax IDs in the accounting data, which incorrectly linked company records. This fix ensures accurate company setup and avoids data inconsistencies.
Original PR description
**STEP TO REPRODUCE** 1. create a company, and set country to Sri Lanka. 2. create a 2nd company, and do the same. 3. There is a company inconsistencies error. **CAUSE** There is 2 taxes defined in `account.tax-lk.csv` with `.` in their id. This messes up with the function `company_xmlid()`: we end up loading the `account.tax` record of the 1st company when saving the 2nd company. opw-5473952 Forward-Port-Of: odoo/odoo#245244
This update resolves an issue where the Point of Sale 'Settle Due' feature was blocked when ZATCA integration was enabled. The fix prevents the system from incorrectly forcing an invoice, allowing users to properly complete settlement payments without needing to create a new invoice for ZATCA.
Original PR description
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale…
## Dependent PR https://github.com/odoo/enterprise/pull/98463 ## Description of the issue/feature this PR addresses: Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled. ## Current behavior before PR: When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA. However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because: - Settlement orders do not contain any lines, so a new invoice cannot be generated. - The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice. Thus, the user cannot proceed with the settlement. ## Desired behavior after PR is merged: After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244654 Forward-Port-Of: odoo/odoo#233769
This update resolves an issue where a Point of Sale order incorrectly remained flagged as a 'settlement' after a user cancelled a payment attempt. By resetting the order flag, this prevents users from bypassing important business rules related to invoicing and reporting. This ensures accurate order processing and compliance.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. task-id - 5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#104866 Forward-Port-Of: odoo/enterprise#98463
This update resolves an issue where applying text colors to lists in the HTML editor didn't correctly color the list markers. The fix ensures that text color classes remain on list items, resulting in consistent and accurate color matching for list markers. This improves the overall user experience when formatting lists.
Original PR description
### Steps to reproduce: - Create a list and type some text. - Press Ctrl + A and apply a text color from the toolbar. - Observe that the list marker is not colored. ### Description of the issue/feature this PR addresses: - `getFonts` looked for the closest element with a text color class, and this also matched `<li>` elements. When a `<li>` was selected, its text color class was removed and moved to a new <font> element created inside the `<li>`. - As a result, the color class was removed from the list item itself, which broke list marker coloring. ### Desired behavior after PR is merged: - Text color classes remain on list item, so list markers are colored correctly. task-5454639 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243005
This update fixes a bug that prevented customers with names like "constructor" from being correctly processed in reporting. The change avoids issues with object initialization, ensuring customer names can be used without causing errors. This improves the reliability of customer reporting features.
Original PR description
Steps:
- Have a customer named "constructor" (or any valid json prototype key value)
- Install `sale_management`
- Create a sale order with "constructor"
- Open Reporting -> Customers
- Traceback `Caused by: TypeError: groupedDataPoints[key].push is not a function`
This problem occurs because we use the client name directly in an object, and “constructor” already exists in all objects but is not initialized correctly, which raises a traceback.
One solution is to use `let object = Object.create(null)` instead of `let object = {}`, which prevents inheritance of `Object.prototype` properties.
https://github.com/odoo/odoo/blob/5e74f04ff35ed3efa25be295567be41f42024692/addons/web/static/src/views/graph/graph_model.js#L451-L457
opw-5474691
Forward-Port-Of: odoo/odoo#245369
Forward-Port-Of: odoo/odoo#245206This update resolves a bug where self-order kiosks were printing blank tickets. The fix ensures that preparation printers without categories are not used for printing, aligning with the expected behavior of the self-order system. This prevents unnecessary printing and improves the kiosk experience.
Original PR description
Before this commit: To reproduce (version 17 and >): 1. Install Restaurant 2. In PoS restaurant config allow "Self ordering" in Kiosk mode and enable "Preparation printers" 3. Create a preparation printer with NO categories and set it as a restaurant preparation printer 4. Open the Kiosk 5. Make an order with any product and checkout -> Printer will print a ticket with no product <img width="512" height="415" alt="image" src="https://github.com/user-attachments/assets/31bd08f9-2470-4f72-9e3d-822564b43f70" /> After this commit: No kitchen printer is printed (expected as no category set on the kitchen printer) Forward-Port-Of: odoo/odoo#245353 Forward-Port-Of: odoo/odoo#245193
This update fixes a test failure related to user assignments within work orders. The previous test setup caused a constraint error when multiple employees were assigned to the same user in succession. The fix involves using a different user during assignment to avoid this constraint, ensuring the work order functionality remains stable.
Original PR description
Before this commit, the test `test_allowed_employees_restriction` was failing because two different employees of the same company were assigned one after another to a same user. When the changes are commited, the constraint `_user_uniq` was triggered. Solution: use a different user instead of reassigning to the same one so that the constraint isn't triggered when setting another employee to the user. fixes odoo/enterprise#96931 runbot error 234537
A minor bug in the knowledge calendar tour was preventing it from completing correctly. This update fixes a reference error, ensuring the tour now successfully guides users through the property deletion process. This improves the overall user experience for the knowledge module.
Original PR description
In test_knowledge_calendar_command_tour there was a miss-referenced button towards the end. This caused the tour to fail because it didn't find the button to click. With this PR we correctly reference the button and allow the tour to finish. Runbot Error: 234898
This update fixes an issue where the FedEx rate selection process was failing when the requested currency didn't match the account's currency. The fix ensures the 'PREFERRED' rate type is consistently used, preventing errors and ensuring accurate shipping calculations. This improves the reliability of our FedEx integration.
Original PR description
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the…
Issue ----- Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means `d['rateType'] == rating_result['actualRateType']` is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`. Solution ----- In the request we send, we hardcode `'rateRequestType': ['PREFERRED']` so we can look for a match using 'PREFERRED' as a prefix of `rateType`. The Fedex API lists all possible values of the enum `rateType` https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html <details> <summary>Enum values as per the API</summary> "enum": [ "INCENTIVE", "NEGOTIATED", "PAYOR_ACCOUNT_PACKAGE", "PAYOR_ACCOUNT_SHIPMENT", "PAYOR_CUSTOM_PACKAGE", "PAYOR_CUSTOM_SHIPMENT", "PAYOR_LIST_PACKAGE", "PAYOR_LIST_SHIPMENT", "PAYOR_RETAIL_PACKAGE", "PAYOR_RETAIL_SHIPMENT", "PREFERRED_ACCOUNT_PACKAGE", "PREFERRED_ACCOUNT_SHIPMENT", "PREFERRED_CUSTOM_PACKAGE", "PREFERRED_CUSTOM_SHIPMENT", "PREFERRED_INCENTIVE", "PREFERRED_LIST_PACKAGE", "PREFERRED_LIST_SHIPMENT", "PREFERRED_NEGOTIATED", "PREFERRED_RETAIL_PACKAGE", "PREFERRED_RETAIL_SHIPMENT", "RATED_ACCOUNT_PACKAGE", "RATED_ACCOUNT_SHIPMENT", "RATED_CUSTOM_PACKAGE", "RATED_CUSTOM_SHIPMENT", "RATED_LIST_PACKAGE", "RATED_LIST_SHIPMENT", "RATED_RETAIL_PACKAGE", "RATED_RETAIL_SHIPMENT", "UNKNOWN" ], </details> There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe. ----- Ticket: opw-5482949 Forward-Port-Of: odoo/enterprise#105156
This update fixes errors related to tax processing within the HR:E category and improves compatibility with the UBL tax extension. It now displays warnings for invoices that fail to fiscalize correctly, rather than silently skipping them, providing better visibility for users. This ensures accurate tax calculations and a smoother user experience.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245625 Forward-Port-Of: odoo/odoo#245028
This update resolves an issue preventing some users from submitting VAT declarations, even without specific access rights within the system. By adding temporary sudo permissions, the system now ensures all users can complete the process, improving compliance and reducing potential delays. This change enhances the user experience and simplifies VAT reporting.
Original PR description
Add few sudo() for vat declaration, to be sure users without access rights to res.company or certificate.certificate can still make a submission. task-5470492 Forward-Port-Of: odoo/enterprise#103647
This update fixes an issue where the system incorrectly prevented users from setting different cost shares for by-products based on product color. The change ensures that the total cost share for a Bill of Materials remains within the 100% limit, regardless of the specific color variant used for the by-products. This improves flexibility and accuracy in managing product costs.
Original PR description
### Steps to reproduce: - In the settings enable By-Products - Create a product with an color attribute and 2 values: white, black - Create a bom for that products and add 2 by product lines: - 1 x…
### Steps to reproduce:
- In the settings enable By-Products
- Create a product with an color attribute and 2 values: white, black
- Create a bom for that products and add 2 by product lines:
- 1 x comp1 with a cost_share of 50% specific to the white att-value
- 1 x comp2 with a cost_share of 70% specific to the Black att-value
#### > Try to save and you will raise a UserError: The total cost share for a BoM's by-products cannot exceed 100.
### Expected behavior:
The error should not be raised as the total cost_share is 50% for the white variant and 70% for the black one but none of them exceeds the 100% cost share.
### Cause of the Issue:
Currently the constraint does not take attribute values into accounts and simply sums the value of the cost share of all by-product lines: https://github.com/odoo/odoo/blob/bcc1397c7d694dbe61ecbd44d0320b9518df84cb/addons/mrp/models/mrp_bom.py#L201-L202
### Fix:
Just as for the total cost_share on kit products, we rely on the exclusion util and check for each existing product variant if the cost share set up is valid:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/purchase_mrp/models/mrp_bom.py#L20-L23 see 3832793e3ce61aff0c7cf4673de84645a3469b3a
opw-5499773
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245441This update removes a problematic default payment method (`99 – Por Definir`) used in MX e-invoicing invoices, sale orders, and POS orders. This change corrects a fiscal inconsistency, particularly with the ‘PUE’ payment policy, ensuring compliance. The fix clarifies data requirements for users.
Original PR description
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE`…
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid ### Cause: In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir` ### Fix: After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank ### Steps to reproduce: - Install `l10n_mx_edi` and switch to the MX company - Create an invoice with today’s invoice date - The payment policy is set to PUE - Before the fix, the payment method is set to `Por Definir` For Sale Order and POS Order tests, it's the default value as soon as you create an order opw-5406038 Forward-Port-Of: odoo/enterprise#105220 Forward-Port-Of: odoo/enterprise#104164
This update fixes an issue where iOS users were unable to save custom star ratings for product reviews. The problem stemmed from a technical glitch that reset the rating to the default value before submission. This change ensures that iOS users can accurately submit their product ratings, improving the overall customer experience.
Original PR description
## Versions
18.0+
## Issue
On iOS devices, when submitting a product review with a custom star rating, the selected value would revert to the default (4 stars) before submission.
## Steps to reproduce
*On a laptop*
- Open Editor mode on a product eCommerce page:
- Select any product element (e.g. click on the price);
- Activate customer ratings and save.
*On a physical Apple mobile device (iPhone or iPad) or on an iOS emulator via XCode (only on MacOS)*
- Go to the product's eCommerce page:
- Move down to the "Customer Reviews" section and un-toggle it:
- Write down a review;
- Click on any star rating but 4;
- Send.
## Cause
`mouseleave` event is triggered before the rating is saved and resets the rating to the default 4-star one.
## Solution
Only trigger `mouseleave` event on devices handling them correctly and post the number of visible stars on the form.
opw-5142682
Forward-Port-Of: odoo/odoo#245135
Forward-Port-Of: odoo/odoo#234308This update resolves a bug that caused a RecursionError when producing large quantities of serial-tracked products. The issue stemmed from a process that repeatedly updated deadlines, leading to excessive recursion. This change ensures stable production runs for high-volume manufacturing.
Original PR description
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture…
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled). - Create a BoM for product A containing product B. - Create a BoM for product B containing product C. - Create a BoM for product C containing another product. - Create a manufacturing order of 100 units for product A and confirm it. - Produce the 100 units on the child MO of product C (100 backorders are created). - On the main MO (product A), click on "Prepare MO". - Attempt to produce product B. → RecursionError: maximum recursion depth exceeded. **Cause** While setting `move_finished_ids`: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806 the `deadline_date` of the final move is updated: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63 This deadline is then propagated to chained moves: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55 via: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61 This propagation retriggers the `move_finished_ids` setter recursively on other moves. The recursion depth grows with the number of generated moves, eventually exceeding Python's maximum recursion limit. opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#239648
This update resolves an issue where scale readings weren't being properly transmitted to the user interface after a measurement. Previously, the system didn't automatically send weight data following the 'read_once' action for scales. This change ensures that scale readings are now reliably delivered to the frontend, providing accurate data.
Original PR description
Since odoo/odoo#237586, events are no longer automatically sent after actions are executed. Since the `read_once` action for scales did not return a value or send an event, this meant it never returned the weight to the frontend. This commit simply returns the weight value directly from the `read_once` action. Enterprise: https://github.com/odoo/enterprise/pull/105324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the system correctly processes weight readings from the scale, even when those readings are triggered by a specific 'read_once' action. This improves the reliability of scale data integration, ensuring accurate weight information is consistently captured and used within the system. It addresses a minor technical issue related to response handling.
Original PR description
This commit adjusts the callback when a new weight is received from the scale to also handle the case where it is the response to the `read_once` action. In this case, the `status` key is `success`.
This update resolves intermittent errors in the mass mailing functionality, specifically related to saving data and handling user interactions. The team adjusted the system's response time to ensure stability during complex operations, and also addressed a potential conflict issue within the email editor field.
Original PR description
After the previous [fix], other non-deterministic errors were revealed. It seems `200` ms is sometimes too little for operations involving multiple async calls like `save` on the mass_mailing form view, and display the style option in the `html_builder` when clicking on a block. The `body_html` field is displayed in readonly as we never need to use the editor for this field. This prevents selection/event conflicts between 2 editors at the same time which is something that we don't want to test in `mass_mailing`. [fix]: https://github.com/odoo/odoo/commit/a180d09aaf0661483670a79deedc3223a0b6e621 runbot-error-238002 runbot-error-238045 task-5866753
This update resolves a previous issue where printing was significantly delayed while waiting for printer connections. By allowing each printer driver to manage its own connection, the system now avoids long waits and ensures faster printing performance. This improves the overall user experience when generating reports and documents.
Original PR description
Before this commit, the `printer_interface_L` and `printer_driver_L` shared a single `cups.Connection` instance guarded with a `Lock`. This meant that while the interface for checking for new printers (which can take 10-15 seconds), all printers were being blocked from printing until it was finished. After this commit, each driver creates its own `cups.Connection` and `Lock`. This means they should never block each other, and prevents long pauses when trying to print. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245100 Forward-Port-Of: odoo/odoo#245012
This update corrects a technical inconsistency where employee-related fields were incorrectly marked as editable. The change ensures that fields marked as 'readonly' in the version record are consistently 'readonly' for the employee record, preventing unintended data modifications. This resolves a potential data integrity issue.
Original PR description
There was an inconsistency on readonly for fields between version and employee. This removes "readonly=False" on employee for fields that are readonly on the version. Runbot error: 230983 Forward-Port-Of: odoo/enterprise#100575
This update fixes an issue where Odoo wasn't correctly assigning a plan ID when multiple schedulers were involved in a single task. The change ensures that the correct plan ID is consistently used, improving the reliability of scheduling processes. This update was a necessary correction to the existing functionality.
Original PR description
Description of the issue/feature this PR addresses: Same pattern as in https://github.com/odoo/odoo/pull/189843 but for _compute_plan_id method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243307
This update fixes an issue where zero-percent NT/NA/EXEMPT taxes were incorrectly filtered out of downpayment calculations. Previously, these taxes weren't properly accounted for, leading to inaccurate financial reporting. This change ensures that all relevant taxes, including zero-percent NT/NA/EXEMPT, are correctly applied during downpayment creation.
Original PR description
Taxes 0% NT and 0% EXEMPT should not be fixed taxes. This is causing issue in some cases such as downpayments, where those taxes needs to be present, but fixed taxes are filtered at the creation of the downpayment. opw-5815953 Forward-Port-Of: odoo/odoo#245570 Forward-Port-Of: odoo/odoo#245252
This update resolves an issue where full payments on invoices with installment payment terms resulted in incorrect and duplicated cash basis tax calculations. The fix ensures that only the remaining balance's tax is recorded when a full payment is made, aligning with the intended batch processing functionality. This improves the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to…
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a `Cash Basis Transition Account`. 4. Create an invoice with the cash basis tax and a payment term such as `30% now, balance in 60 days`. 5. Record a full payment on the invoice instead of just the first installment. 6. Review the generated cash basis journal entries. **Observed behavior:** * Cash basis entries are created for the full tax amount, not proportionally. * Paying the full invoice with payment terms causes duplicated tax entries. This came from the fact that we didn't consider a move would be fully paid by several lines at the same time, like with installments. We now only put the leftover amount when the move is fully paid and we're on the last partial. Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches opw-5061136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244733 Forward-Port-Of: odoo/odoo#236536
This update enhances the message list functionality by providing more specific error details when loading messages fails. Previously, users only saw a generic 'Ann error occurred' message. Now, the commit displays the underlying error message, giving support teams a clearer understanding of the issue and its potential cause.
Original PR description
Backport of https://github.com/odoo/odoo/pull/244094 Before this commit, when message list failed to load, it just displays a "Ann error occurred" generic message with a retry button. This assumes that error happens rarely and when so this is temporarily. However some errors are persistent and it's frustrating to have no clue on why there's error or what may have caused it. This commit shows the `Error.toString()` from fetch message RPC failure on UI, so that there's a clue on the reason the fetch of messages failed. Before / After <img width="305" height="67" alt="Screenshot 2026-01-20 at 15 10 38" src="https://github.com/user-attachments/assets/34c546df-71e6-4055-9f85-8d85a9c89b35" /> <img width="334" height="100" alt="Screenshot 2026-01-20 at 15 09 07" src="https://github.com/user-attachments/assets/5fadd0b7-7ea0-43ca-8c28-0ac1d33650ff" /> Forward-Port-Of: odoo/odoo#245150 Forward-Port-Of: odoo/odoo#244754
This update fixes a visual issue where 'Danger' and 'Success' buttons weren't consistently appearing for actions in the portal. The change ensures these buttons are correctly displayed, regardless of whether the action is shown in the dropdown or quick action menu, improving the user experience.
Original PR description
PR #224976 fixes the demonstration of an action with a `DANGER` tag in the dropdown menu in the action list. Such an action may not be located in the dropdown, but rather in the quick action menu. This change ensures that the action buttons with `DANGER` or `SUCCESS` tags are demonstrated properly in either case. Steps to reproduce: - Open a document in the portal as a portal user. - Send a message and hover over the message. - The `delete` button is not visible in the action list. Forward-Port-Of: odoo/odoo#244954
This update resolves an issue where product pages would appear grayed out and inactive when a product had multiple attributes and one variant was archived. The fix ensures that inactive variants are not considered during product display, allowing customers to correctly see and add available products to their cart. This improves the overall shopping experience.
Original PR description
### Issue: When a product has multiple attributes and one variant is archived, the product page may appear grayed out and the product cannot be added to the cart. #### Steps to reproduce (with demo…
### Issue: When a product has multiple attributes and one variant is archived, the product page may appear grayed out and the product cannot be added to the cart. #### Steps to reproduce (with demo data): 1- Create a product with two attributes: - attribute with 3 values - Brand: Adidas 2- Save product to generate variants. Publish the product. 3- From variant list, archive the first variant 4- Back in product page, from attributes & variants tab, remove the first value. This sets `ptav_active` to False. 5- Navigate to website shop page, and add the Brand Adidas to filter 6- This should show the created product active. 7- Open the product. You will see the product is grayed out and it's shown inactive and cannot add it to the cart. ### Cause: In this scenario, `attribute_value_ids` only contains values from the single-value attribute: https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L814-L824 For the multi-value attribute, no ptav matches `attribute_value_ids`, so the code falls back to selecting the first ptav: https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L823 If this ptav corresponds to an archived variant, the resulting combination resolves to an inactive product. ### Fix: Ensure the fallback logic only considers active ptavs, preventing archived variants with prav inactive from being selected. opw-5352224 Forward-Port-Of: odoo/odoo#244049
This update fixes an issue where light dropdown menus in the Discuss app caused eye strain when using the dark theme. By adding a background color adjustment, the menus now blend better with the dark theme, significantly improving readability and user comfort. This enhances the overall user experience within the Discuss app.
Original PR description
Dropdown menu are quite light in dark theme. Outside of discuss not many UI elements require dropdown. However discuss use them a lot, so this becomes a problem to have light background so often. This commit adds `.bg-view` to all discuss dropdown, which is visually unchanged in white theme but in dark theme this makes it darker so easier to read with less eye strain. Task-5492040 Before / After <img width="961" height="671" alt="Screenshot 2026-01-13 at 17 24 12" src="https://github.com/user-attachments/assets/09ab5f8f-5927-4beb-a814-d77cd61f8a01" /> <img width="957" height="667" alt="Screenshot 2026-01-13 at 17 23 56" src="https://github.com/user-attachments/assets/4ec0ef3b-7af5-4b69-b48e-40c3788eb95e" /> Forward-Port-Of: odoo/odoo#243599
This update fixes an issue where the tax code (9) was missing from Datev exports for expense journal entries when using 19%I tax. The problem stemmed from how payment amounts were aggregated, leading to data loss. This ensures accurate tax reporting in Datev.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105435 Forward-Port-Of: odoo/enterprise#102548
A bug in the live chat feature was causing freezes due to a feedback loop when updating information across multiple tabs. This update fixes the issue by preventing the live chat state from continuously updating in local storage, ensuring smoother operation and preventing potential disruptions. This improves the overall stability of the live chat experience.
Original PR description
Since [1], the live chat info panel state is saved to the local storage. Writing the livechat info panel state to local storage on every field change (especially coming from the storage event itself) caused a retroaction loop across tabs, leading to potential freezes. For example: - Tab A writes OPEN to local storage. - Tab B receives OPEN and updates its field. - Tab A writes CLOSE, local storage updated. - Tab B, based on stale state, writes OPEN back to local storage. - Tab A receives OPEN, updates its field, writes CLOSE again. This PR fixes the issue: the field is only written on direct user action and the computeed field is invalidated on storage event, effectively breaking the loop. [1]: https://github.com/odoo/odoo/pull/238472 Forward-Port-Of: odoo/odoo#245697
This update adjusts the location of configuration files within the IoT drivers, ensuring they can be correctly identified and upgraded after a recent system change. This change is necessary to maintain the functionality of the IoT drivers and prevent potential issues with package updates. It’s a routine maintenance task.
Original PR description
As we moved configuration folder in `setup/iot_box_builder`, we need to adapt the path to find them. Related PR: https://github.com/odoo/odoo/pull/229698
This update fixes an issue where the Follow-Up Report displayed full account amounts instead of the remaining amounts when reconciled entries were present. This change ensures users accurately see the outstanding balances, improving reporting and financial analysis.
Original PR description
Currently, when viewing the followup report with reconciled entries, we display full amounts instead of the residual amounts. task-5868881
This update fixes issues where self-order pricing didn't consistently apply pricelist rules to product variants. Now, the checkout page and product pages accurately display the correct price based on the selected variant and associated pricelist rules. This ensures accurate pricing for self-order transactions.
Original PR description
This PR fixes 2 bugs in self order when we are dealing with variants. The first bug in commit https://github.com/odoo/odoo/commit/0cd3a64955052b7fb5507f8fbb3414e0a894250d The order pricelist_id was…
This PR fixes 2 bugs in self order when we are dealing with variants.
The first bug in commit https://github.com/odoo/odoo/commit/0cd3a64955052b7fb5507f8fbb3414e0a894250d
The order pricelist_id was not taken into accounting when adding a line corresponding to a product variant. So any price rules acting on the variant, that are specific to the current pricelist, will not be applied.
The second bug in commit https://github.com/odoo/odoo/commit/77dbf4b2cf1b1dea3bb5ba107da83e13e5283afb
The product page was displaying the price of the default product, instead of that of the selected variant.
A third commit https://github.com/odoo/odoo/commit/bf2e3d90e3f3405db9be78acfdf2558bf47b449a was to fix `price_extra` calculations and make it consistent between the product page and the rest of the app.
I have included the steps to reproduce and more details about the fixes separately in each commit.
However, the reproduction steps are the same:
1. Make a product with 2 variants, size S and M for example.
2. Create 2 pricelists, A and B, and make them available in PoS. The
default one should be A.
3. For the created product, create 2 price rules:
1. One changing the price of the variant S for the pricelist B
2. One changing the price of the variant M for the pricelist B
4. Enable mobile self order and create a peset that applies the
pricelist B
5. Open self order, and select that preset (it should apply the
pricelist B).
6. Select the product of step 1, and choose the variant M.
opw-5467593
Forward-Port-Of: odoo/odoo#243304This update fixes a problem with the Point of Sale tour, ensuring it consistently guides users through the setup process. The team addressed a generic error message and a timing issue within the tour, improving the overall user experience. These changes were made to enhance the ease of use for new Point of Sale users.
Original PR description
In this commit, we add few steps in the tour to ensure the tour take always the good way. Few python assertions between has been added to know where the unit test fails (easier to debug). We take advantages of this commit to fix few utils: - Dialog.cancel() was too generic. We add at least title to let the possibility to be more precise. - selectPresetTimingSlotHour() has been fixed to wait the good triggers in the DOM before the tour continues. runbot-error-id 237756 runbot-error-id 237762 Forward-Port-Of: odoo/odoo#243799
This update fixes a calculation error in the Austrian VAT tax report. Previously, the report incorrectly subtracted deductible input tax, leading to inaccurate VAT payable or credit figures. The fix adds the deductible input tax to the calculation, ensuring the report accurately reflects Austrian tax regulations.
Original PR description
The Austrian tax report computes line 7 by subtracting the deductible input tax instead of adding it, leading to an overstated VAT payable or understated credit. ### **Steps to reproduce:** - Install…
The Austrian tax report computes line 7 by subtracting the deductible input tax instead of adding it, leading to an overstated VAT payable or understated credit. ### **Steps to reproduce:** - Install `Accounting` app with `l10n_at` localization and switch to AT Company. - Create a customer invoice for some product with price 1000 and 20% Tax. - Create a vendor bill for some product with price 100 and 20% Tax. - Open the Austrian tax report for the corresponding period. ### **Observed behavior:** section-7 shows `-220` instead of the correct amount `-180`. because value of, section-4 = -200 section-5 = 20 section-6 = 0 Current calculation for **section-7 = section-4 - section-5 + section-6** which is equal to `-220` ### **Expected behavior:** 1) Section-4(VAT Computation (U1/U30))- negative value is correct as this is the amount of sales tax which needs to pay to the tax office. 2) Section-5(Deductible input tax computation) and section-6(Other corrections) - are positive values and are added to section-4 as this is the input tax which is get back from the tax office. hence the correct calculation for **section-7 will be section(4+5+6).** ### **Root cause** Since [commit](https://github.com/odoo/odoo/pull/224604/commits/06666fc55a7a3f569a0d15f0827ed8e2199cf51c), introduced a formula that subtracts the deductible input tax(section-5) in section-7, causing the miscalculation. ### **Fix** Update the section-7 aggregation formula to add deductible input tax instead of subtracting it. **opw-5476604** Forward-Port-Of: odoo/odoo#245174
A recent issue preventing the demo mode of the Account PEPPOL module from connecting correctly has been resolved. The fix addressed a minor discrepancy in how the connection was being established, ensuring the demo mode now functions as expected. This improves the usability of the PEPPOL demo for testing and training.
Original PR description
There is one argument too much for the mock of _create_connection compared to the real one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245678
This update resolves an issue where saving link tracker records with URLs (like `https://demo.com`) would cause an error. The fix ensures that URLs entered in the 'Code' field adhere to the required format, preventing the error and allowing users to successfully save link tracker records with URLs.
Original PR description
Saving a link tracker record fails when the user enters a URL in the Code field. Steps to reproduce the error: - Install ``link_tracker`` module - Create a new link tracker record with Target Link >…
Saving a link tracker record fails when the user enters a URL in the Code field. Steps to reproduce the error: - Install ``link_tracker`` module - Create a new link tracker record with Target Link > Save - Edit the record and set Code: ``https://demo.com`` > Save Traceback: ```py ValueError: Extra URL must use same scheme and host as base, and begin with base path ``` https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/link_tracker/models/link_tracker.py#L77 After this commit: https://github.com/odoo/odoo/commit/977e62d91f3e8235e251e9d21b08f53db1856c6b, When the user sets the code as ``https://demo.com``, Error will be raised from [1], because the extra URL must use same scheme and host as base, and must begin with the base path. [1]: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/odoo/tools/urls.py#L55-L58 sentry-7022131826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235491
This update fixes an issue where payment references on Italian invoices were incorrectly populated with a unique invoice number. Now, the payment reference field only uses the actual payment reference provided by the partner, simplifying automated payments and aligning with Italian tax regulations. This ensures accurate reconciliation of payments and improves the efficiency of financial processes.
Original PR description
Description of the issue/feature this PR addresses: The payment_reference field in invoices was being filled with a wrong field from the imported XML, progressivoinvio is the progressive number of invoices sent by the partner's system, not a partner's requested payment reference. Current behavior before PR: On import, payment_reference was being filled with ProgressivoInvio, making automated payments out to partners harder. Desired behavior after PR is merged: payment_reference is only being filled if partner specifies a payment reference in the EDI, avoiding confusion. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245058
This update fixes a visual issue where product attributes with single values were displaying incorrectly with empty borders. The change refines the CSS selector to accurately hide attribute sections, ensuring a cleaner and more consistent user experience for product browsing. This improves the overall presentation of product information.
Original PR description
Before this commit, when a product attribute with display_type 'pills' has only one non-custom value, the parent li.variant_attribute is correctly hidden. However, the CSS :has() selector still matched the inner li.o_variant_pills, causing the attributes section to display with empty borders. This commit refines the selector to only match pills outside of variant_attribute elements (UOM pills). task-5852515 | Current (19.0) | After | |--------|--------| | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/64519161-e552-492f-b010-d1353b07f80a" /> | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/6022e371-18eb-4d2a-99d0-da3c94b291d0" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245175
This update ensures that LNA (a security feature) is consistently enabled for IoT devices across all Odoo POS systems, including kiosks. Previously, LNA was only active in the POS, creating a potential security gap. This change strengthens security and improves the overall performance of self-order IoT devices.
Original PR description
Before this commit, LNA was being used for IoT devices in the POS but not in the Kiosk when `point_of_sale.use_lna` was enabled. After this commit, LNA will also be enabled for IoT devices in the Kiosk. task-5874663 Forward-Port-Of: odoo/enterprise#105460
This update optimizes how category data is loaded on the website, resolving a previous issue that caused excessive memory usage. The change reduces the amount of data processed, leading to faster website loading times and a smoother user experience. This improves overall website performance.
Original PR description
Previously the function was fetching all the product template ids and looping over them for each product template. This triggered the prefetch_ids and prefetch fields for these products which would cause memory issues due to the bloat of the cache from the prefetcher. The current way is a read_group over the categories and check if category id exists or not. 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#239499
This update resolves a visual issue where Marketing blocks sometimes displayed incorrectly due to a problem in how the system converted table layouts. The fix ensures that tables render consistently, regardless of column sizes, preventing layout overflows and maintaining a professional appearance. This improves the overall user experience for users creating and viewing Marketing content.
Original PR description
This reverts commit 0ffb96dedc776552564cec28140340ec38dee9d1. The commit was incomplete and while it prevented the crash, the resulting table did not match the expected layout. Original issue:…
This reverts commit 0ffb96dedc776552564cec28140340ec38dee9d1. The commit was incomplete and while it prevented the crash, the resulting table did not match the expected layout. Original issue: Problem: The grid conversion logic only finalized a row when iterating through the last column in the input list. If a row reached exactly 12 grid spans while more columns remained (e.g., a `col-12` in the middle), the logic did not start a new row. As a result, remaining columns overflowed the current row visually. Cause: In a single row, if a column had a size 12 and was followed by another column of any size, it would crash because the algorithm did not reset the index to the start of the next row. Steps to reproduce: - Add a Marketing block. - Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" /> - Save. - Traceback. Solution: This more thorough fix properly handles all problematic aspects: - filter conflicting `col-x` instructions on a single element to keep only one size - ensure that a gridIndex of 12 does not cause a crash in the algo - properly add all effective `td` in a row in all circumstances (there where cases where the final row could be omitted) opw-5439481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245674
This update resolves an issue where Stripe-created expense records were being duplicated, causing confusion and errors in the system. By preventing the duplication, we ensure accurate expense tracking and streamline the process for employees. This improves data integrity and reduces potential reconciliation problems.
Original PR description
Prevent expenses automatically created by Stripe Issuing to be duplicated. Currently, it adds a lot of noise on customer dbs. The payment method is duplicated and it can lead to errors (eg: employee submit duplicatas instead of the original expenses. The automatic reconciliation doesn't happen afterwards) task-5246475 Forward-Port-Of: odoo/enterprise#102034
This update resolves issues where smart buttons on VoIP call forms were missing access groups, causing errors and incorrect numbers to display. The fix ensures these buttons function correctly, improving the user experience when initiating VoIP calls across various modules like CRM, Helpdesk, and Sales.
Original PR description
1. Tickek/Application smart buttons on voip.call form miss access groups. 2. In voip.call form, when clicking the application smart button, a singleton error will raise. 3. Incorrect numbers on smart button. Task-[5461729](https://www.odoo.com/odoo/5778/tasks/5461729) Forward-Port-Of: odoo/enterprise#103233